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
SoftPerfect Support Forum
All Forums
► RAM Disk & RAM File System
► Current topic
Suggestions for ramfsctl CLI
|
Suggestions for ramfsctl CLI 31 August 2026, 13:14 |
Registered: 1 year ago Posts: 3 |
|
|
Re: Suggestions for ramfsctl CLI 31 August 2026, 19:14 |
Admin Registered: 20 years ago Posts: 2 098 |
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.
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.
|
Re: Suggestions for ramfsctl CLI 02 September 2026, 03:21 |
Registered: 1 year ago Posts: 3 |
Thank you for the explanation, yes I do understand how it works , but ...
I am asking that the disks created with ramfsctl create to be shown in UI and if we can add autosave for the disks like that? I dont want to use ramfsct auto.
cheers.
P.S. the folder mapping is brilliiant but I would need it to script to be more usable ..
thanks a lot!
I am asking that the disks created with ramfsctl create to be shown in UI and if we can add autosave for the disks like that? I dont want to use ramfsct auto.
cheers.
P.S. the folder mapping is brilliiant but I would need it to script to be more usable ..
thanks a lot!
|
|
Re: Suggestions for ramfsctl CLI 03 September 2026, 23:32 |
Admin Registered: 20 years ago Posts: 2 098 |
Both landed in 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:
Then your everyday script is just:
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.
Grab the update and let us know how it goes.
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.
Grab the update and let us know how it goes.