Suggestions for ramfsctl CLI

Hey guys! First of all, your RAM FS software totally rocks!

May I suggest/request a few improvements?

To use a source folder for software dev, I want replace my folder with the RAM disk using the current folder as a source, then I want to develop software for a bit, then turn it off to be sure all changes are back in place.

With software development there are a lot of writes, i.e. bin folder, node_modules, etc. So I tried to write a script that would replace current folder with drive B:
The process would be:
1) replace a source folder with RAM disk
2) do the work
3) unmount the disk once done
I was intending to use ramfsctl.exe with the create option.

I have encountered 2 problems:
a) when I use ramfsctl create, the disk is not shown in the UI.
b) the autosave option is missing, which I think is the limitation of the platform, not just the UI - autosave seems to be only available for drives created at logon.

I have ended up using the ramfsctl auto that seems to work with both options, but I would still like to use ramfsctl instead as the idea is that the process is temporary. And I would want to have auto save, no one wants to lose a day of work after power loss. Of course there is git and things like that though, but still...

My current scripts are at: https://github.com/marat-365/misc_scripts/tree/main/ramfsctrl

Good news: what you describe is exactly what Folder Mirroring does, added in version 26.8.1. No scripting needed, the driver does the whole swap itself.

In the Add Volume dialog, click Use a source folder instead and pick your project folder, tick Save changes at shutdown, and in Advanced tick Save changes every (minutes) if you want periodic write-back. That is the power loss protection you want

At mount, the folder contents are loaded into the volume before it is published to Windows, the folder on disk is renamed aside to a hidden copy, so C:\Work becomes C:\Work.ramfs, and the original path is turned into a junction to the volume. From then on C:\Work and the drive letter are the same data, so nothing has to be reconfigured: your IDE, your build scripts and your paths all stay as they are.

Saving writes back only the delta. Untouched files are not rewritten, unchanged regions inside a modified file are not rewritten either, renaming a folder with thousands of files costs a single rename on disk, and deletions propagate, so the disk always ends up matching the volume.

At dismount the junction is removed and the hidden copy is renamed back to C:\Work with your changes in it, an ordinary folder again. If the machine loses power, the swap is recognised and resolved at the next mount, so the folder is never left stranded.

If you leave saving off, the folder is loaded into RAM and everything is discarded on dismount, with the original folder reappearing untouched. That is a neat way to run a build or a test suite against real data that must not be modified.

One tip for a dev folder: opening a file through C:\Work goes via the junction redirect each time, while opening it through the drive letter does not. Reads and writes are equally fast either way, but a build that opens thousands of files is better pointed at the drive letter.

Thank you for the explanation.
Yes I do understand how it works, but I am asking for the disks created with ramfsctl create to be shown in UI, and whether we can add autosave for the disks like that. I don't want to use ramfsct auto.

P.S. The folder mapping is brilliant, but I would need it to script to be more usable.
Thanks a lot!

Both are implemented in version 26.9, released today.

ramfsctl mount <letter> mounts a volume from its stored recipe, the same one auto add creates, so size, source and autosave do not have to be repeated on the command line the way create requires. Pair it with manual on the auto add line and the volume never mounts at boot, only when you call mount:

ramfsctl auto add V 8G Work manual autosave period=300 source=C:\Work

Then your everyday script is just:

ramfsctl mount V
:: work
ramfsctl dismount V

Configured once, mounted and dismounted per session, autosave running the whole time in between. It shows in the main window while mounted, same as any other volume, which is the bit you said was missing.

Try the latest release and let us know how it goes.

Thaaaaank youuu!!
Would it work with ramfsctrl create though?
The thing is that I might work with different projects at the time.

I tried the 26.9. Now I am constantly getting this, even when running as admin:

Quote

.\ramfsctl.exe auto add B 18443M Work norecycle wipe autosave period=300 compress=normal source="A:\_gt\_angular_learning"
ramfsctl: store volume configuration failed: busy
(Win32 error 32: The process cannot access the file because it is being used by another process.)

Glad it helps!

Regarding create, no it is still the one-off that stores nothing, so it has no autosave and doesn't show in the main window. mount is the one to use, and having several projects is fine. Give each project its own letter once

ramfsctl auto add P 8G ProjectA manual autosave period=300 source=C:\Work\ProjectA
ramfsctl auto add Q 8G ProjectB manual autosave period=300 source=C:\Work\ProjectB

and then mount P, mount Q, or both, and dismount each when you are done. The only limitation is that the source folders must not sit inside one another.

If you'd rather keep a single letter: dismount it, run auto add again with the other folder, which simply replaces the stored recipe, and mount. That also suits your script if you want the size recalculated each time: keep its auto add, add manual to it, and replace the create line with mount. The auto del in your dismount script can then go, since the recipe is meant to stay.

The busy error isn't a permission problem, so running as admin makes no difference. auto add checks that the folder can actually be moved aside, and Windows refuses that while any process has the folder open as its current directory. Your script moves its own prompt out of the way, but any other process counts too: a terminal or VS Code terminal opened in the project, ng serve or another Node process started there, and so on. We reproduced it here: a command prompt left sitting in the folder gives exactly your error, and the same command succeeds once it's closed.

To see what's holding it, open Resource Monitor, go to the CPU tab and type the folder name into Associated Handles. Close that, along with any editor or dev server that has the project open, before running mount as well, since that's when the folder is actually renamed and open files inside it get in the way too. Once it's mounted you can open everything again, through the folder path or the drive letter.

Hi Andrew, the thing is exact same script worked fine in v26.8.1.

I went through the source on that one. The check that produces the busy error is identical in versions 26.8.1 and 26.9, and the only thing 26.9 changed about it actually makes it more permissive. So neither the upgrade nor your script is at fault: something had your folder open this time that didn't last time.

Worth knowing though, and it makes the whole thing moot: auto add is a one-off. The recipe is stored permanently and survives dismount and reboot, so it only needs running once per project, not once per session. Do it once while nothing has the folder open, and your everyday script can be just:

ramfsctl mount B
:: work
ramfsctl dismount B

This keeps the config step out of your working day entirely, and mount only needs the folder free at the moment you start a session, before the editor is open.

If you do want the size recalculated on every run, keep the auto add where it is, but run the script before opening the project in VS Code or a terminal rather than after.

thank you!
Could you guys just add the autosave option to the ramfsctl create command and make these drives visible in UI?

Adding those to create would really just turn it into auto add plus mount. The main window and autosave both work from a volume's stored settings: the window lists them, and the saver reads them to know which folder to write back to and how often. create deliberately stores nothing, so there's nothing for either of them to find, and a create that stored its settings would be exactly auto add followed by mount.

So the pair already is the create you're asking for, just split in two. If you'd like it in a single step in your script, keep your current auto add line, add manual to it, and follow it with mount:

ramfsctl auto add B 18443M Work manual norecycle wipe autosave period=300 compress=normal source="A:\_gt\_angular_learning"
ramfsctl mount B

Same parameters you pass today, and the volume shows in the main window and saves every five minutes. Next time, run auto add with a different folder or size and it simply replaces the previous settings. manual just stops it mounting by itself at the next boot.