RAMdisk "hybrid" driver needed

I have encouraged a few people to play around with RAMdisks. Generally the feedback is positive. One problem: installers. If we use a RAMdisk for the temp directories, then a "big install" will fill the RAMdisk and crash the installer.

One solution would be a "hybrid" RAMdisk. You would have two size entries. Firstly, the X amount of RAM to use (classic RAMdisk), and then a second Y amount of physical HDD to use if and only if X is full. A "pure RAMdisk" would then have Y set to zero.

It's not very elegant, I know. And probably tricky to implement. But would such a setup be feasible? Does such a hybrid drive make any sense at all? Would this be a useful safetynet in a 24/7 system?

There may be a simpler way to deal with the RAMdisk filling up due to the installer. Since we do installs manually, before we install we could do this:

set temp=C:\temp to use physical HDD when a BIG temp directory is needed

and when installation is finished,

set temp=Z:\temp to use the RAMdisk again (assuming, set up as a Z: drive)

With a couple of shortcuts, the control is just a manual click away. [vlaurie.com]

Thank you for your comments.

It's apparently technically challenging to implement an expandable RAM disk which in case of being full grows and takes up some disk space. May be we can make this possible at a later stage, but this requires research.

As you correctly said manual switching between a RAM and HDD directories assigned to the TMP/TEMP variables would be a good workaround. We'll add a couple of shortcuts to the RAM disk application allowing to quickly set the temporary folder to a hard drive or a RAM disk and publish an update. Stay tuned

Nice tip! But the "option" is in (Ramdisk)/Tools/Settings... and perhaps need to explain what this means. I'm not even sure if I understand it, let alone regular first time user.

(+I noticed a typo in all the window titles)

Thank you, the typo has been corrected

As to the message and its meaning, this basically refers what sort of drive letters the product assigns to the created RAM disks. The letters or links can exist either in the global context or user context.

Practically this means if the user John creates a RAM disk Z and the link is created in the user context (the 'System-wide links to volumes' option is turned off), this disk will not be visible to any other users logged at the same time. On the other hand, if the user John mounts the same disk with 'System-wide links to volumes' turned on, this disk will be visible to any other user as it will be created in the global context.

Some installation programs may fail because they try to access the temporary folder on the RAM disk from a service, which runs in a different security context and the link does not exist from the point of view of the service. In particular, applications using the Windows Installer will fail if the RAM disk is mounted in the user context, as it will be inaccessible to the service. The solution is thereby to create system-wide or global links when the RAM disk is used as a system temporary folder.

This will be later explained in accompanying documentation

OK. Thanks for the explanation! Better make sure this is checked by default... to avoid unnecessary "it dont work" posts.