If I put a 5GB file on the RamDisk, all hell breaks lose every time at boot and shutdown, meaning I get a whole lot of I/O. This suggests it's just copying everything to the folder, regardless of the fact most of the files there are already there and up to date. e.g. it seems to be simply overwriting everything time and time again at shutdown or manual Sync ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Checked or unchecked, doesn't make any difference. Copy an ISO to the RamDisk, Sync manually, it copies to the folder. Sync again, it copies it again to the folder, etc. I was assuming, because it's called "Sync", that it would not copy it again since it's there already with nothing changed ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As its name suggest, the option I was speaking of relies on the archive attribute of each file.
The synchronization feature is meant to be used at system shutdown. This is why, for performance reasons, the archive attribute of the files on the ramdisk is not changed (because they are all about to be disappear).
As the manual synchronization uses the same procedure, the archive attribute will be kept and therefore, the file will be copied again.
I could add something to clear the archive attribute in the case of a manual synchronization, but there is a risk, because the copied file can still be written while the copy, and as far as I know, there is no way to know that.
If this occurs, the archive attribute will be clear, but the file will be different and it will not be saved at shutdown.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This doesn't work for my particular use case. I also found that at start of RamDisk where it loads up the data, sometimes the resulting data on the RamDisk becomes somewhat corrupted. For example I cannot open a folder, saying "access denied", where I can open it using cmd, but I also cannot delete the folder. I don't know how you implement this, but the loading and saving goes way faster than what you can achieve yourself in the VM (using robocopy). Also, it happens completely async, which is bad for my use case (I'm changing things after loading and change things back before shutting down. Don't bother, you designed it for a different purpose than mine here, so I find it my own responsibility for my use case, thus I turned it off again and are doing my own sync (using robocopy /mt at boot up and rsync at shutdown).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To copy data at ramdisk mounting, I use xcopy (for compatibility with XP).
I was just playing with it and with some syntaxes, I got something similar. It removed all the ACL of the root folder of R: !
No such issue with the syntax used by RamDiskUI though.
Anyway, I would like to know how you get what you describe. This is definitely not a data corruption but "only" an ACL issue.
The synchronization at shutdown relies on the BackupRead/BackupWrite API. ACL are copied along with data.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The issue occured sometimes inside a VM, which has Dynamic Memory (Hyper-V) enabled, but not enough memory for what needs to be loaded in. Specifying RamDisk using AWE mem. was on, so windows would NOT turn to the pagefile for mem., upon which imDisk returned with a write-error. That's where the "corruption" came from. Solved that by specifying RamDisk NOT using AWE mem., so Windows turns to the pagefile, preventing the error, albeit defeating my main purpose ofcourse in that case, because you're effectively loading up the RamDisk to pagefile that way, causing more I/O instead of saving I/O. Anyways, this is just a corner case anyhow and can be prevented by giving the VM enough Startup-Mem. to be able to load the initial RamDisk contents without problems.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If I put a 5GB file on the RamDisk, all hell breaks lose every time at boot and shutdown, meaning I get a whole lot of I/O. This suggests it's just copying everything to the folder, regardless of the fact most of the files there are already there and up to date. e.g. it seems to be simply overwriting everything time and time again at shutdown or manual Sync ?
"Copy only files with Archive attribute" should prevent what you describe.
Did you checked this option?
Checked or unchecked, doesn't make any difference. Copy an ISO to the RamDisk, Sync manually, it copies to the folder. Sync again, it copies it again to the folder, etc. I was assuming, because it's called "Sync", that it would not copy it again since it's there already with nothing changed ?
As its name suggest, the option I was speaking of relies on the archive attribute of each file.
The synchronization feature is meant to be used at system shutdown. This is why, for performance reasons, the archive attribute of the files on the ramdisk is not changed (because they are all about to be disappear).
As the manual synchronization uses the same procedure, the archive attribute will be kept and therefore, the file will be copied again.
I could add something to clear the archive attribute in the case of a manual synchronization, but there is a risk, because the copied file can still be written while the copy, and as far as I know, there is no way to know that.
If this occurs, the archive attribute will be clear, but the file will be different and it will not be saved at shutdown.
This doesn't work for my particular use case. I also found that at start of RamDisk where it loads up the data, sometimes the resulting data on the RamDisk becomes somewhat corrupted. For example I cannot open a folder, saying "access denied", where I can open it using cmd, but I also cannot delete the folder. I don't know how you implement this, but the loading and saving goes way faster than what you can achieve yourself in the VM (using robocopy). Also, it happens completely async, which is bad for my use case (I'm changing things after loading and change things back before shutting down. Don't bother, you designed it for a different purpose than mine here, so I find it my own responsibility for my use case, thus I turned it off again and are doing my own sync (using robocopy /mt at boot up and rsync at shutdown).
To copy data at ramdisk mounting, I use xcopy (for compatibility with XP).
I was just playing with it and with some syntaxes, I got something similar. It removed all the ACL of the root folder of R: !
No such issue with the syntax used by RamDiskUI though.
Anyway, I would like to know how you get what you describe. This is definitely not a data corruption but "only" an ACL issue.
The synchronization at shutdown relies on the BackupRead/BackupWrite API. ACL are copied along with data.
The issue occured sometimes inside a VM, which has Dynamic Memory (Hyper-V) enabled, but not enough memory for what needs to be loaded in. Specifying RamDisk using AWE mem. was on, so windows would NOT turn to the pagefile for mem., upon which imDisk returned with a write-error. That's where the "corruption" came from. Solved that by specifying RamDisk NOT using AWE mem., so Windows turns to the pagefile, preventing the error, albeit defeating my main purpose ofcourse in that case, because you're effectively loading up the RamDisk to pagefile that way, causing more I/O instead of saving I/O. Anyways, this is just a corner case anyhow and can be prevented by giving the VM enough Startup-Mem. to be able to load the initial RamDisk contents without problems.
Speaking of Syn to Folder,
Is it possible to schedule Synchronization on time interval ?
Syn every 10 mins ?
Well, that could be added, but why do you need that?
I want to use freefileSyn (freefilesync.org) to do partial sync to save shutdown time.