2 minor questions:
1) Would it be possible in furture versions to have the installer carry the version in the FileVersion Property ?
This would enable my scripts to auto-detect a newer version and silently install it over the older one.
If it's just a small feat that would be very nice. Thanks
2) Does a dynamicly allocated RamDisk support sparse-files ? They do seem to work properly, but would rather
have an official answer prior to general use.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1) This could be done but... Do you mean that you download the installation package just to know whether it's a newer version?
Various websites are able to publish the new version only a few hours after I uploaded it on SourceForge, so it should be easy. You can simply check for instance if an URL such as https://sourceforge.net/projects/imdisk-toolkit/files/20161204/ exists.
2) What do you mean? For an image file loaded before the volume is mounted, or in a mounted volume?
For an image file, it's not an issue, because the system reconstitutes all the data for an application that is reading the file.
For a sparse file created in the volume, with the TRIM commands, it's the system that decides where are the area to free, so it should be OK.
And with the cleanup function, I don't rely on the size of the files but on the size of the free space.
About data written, this is not filesystem-dependant.
So in any case, I see no problem with the use of sparse files.
Last edit: v77 2016-12-05
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1) No. I have scripts which check the version installed right now by checking the Registry (PoSH: (Get-ItemProperty "HKLM:Software\Microsoft\Windows\CurrentVersion\Uninstall\ImDiskApp" -ea:0).DisplayVersion)
From there, my scripts know wether to support Trim and/or Compression. WOuld like to add a routine that checks the FileVersion of the installer ImDiskTK.exe, compares it with above Reg-entry, and initiates a silent install (=update) if the installer is newer. I do this from a controlled folder, in other words, only if I put a newer version in that folder would all scripts on all servers detect that and update automagically. Much better than updating it manually on 100+ servers :-)
Since you use the date as version, and I don't know when you're gonna post a new version (which I want to test beforehand anyway) adding this version/date to the FileVersion Property would enable above scenario for us. Would be nice. Added benefit would be: Now I do this manually, and after startup a RamDIsk is already in place, then updating means the existing RamDisk gets removed, also removing al my Redirection, which is not really what I would prefer :-)). If the startup script could do the above, it would update before a ramdisk actually gets created, thereby eleminating the need for manual labour, losing data from already existing ramdisk, and no need for a reboot on top of that...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you only knew... ;-)
I have many uses for it. Like redirecting the entire Windows Update Engine to a Dynamic RamDisk. All downloads and updating occurs almost entirely in Ram. Same for any of the many processes Windows has that all generate alot of useless I/Os, like Event logs, Event Traces, parts of the CBS engine, Temp Folders of all profiles, including SystemProfile,Local Service, Network Service, etc.
Any writes that can later be discarded get redirected to Ram. On top of doing this in all VMs, doing the same on physical Hyper-V Servers, redirecting VM BIN (Used Memory layouts) and Checkpoints, as they are temporary in nature anyway. This results in unprecedented performance for all kinds of Maintenance like updates, defrags, cleanups, etc. while sacrificing nothing of value at reboot.
Many thankx in advance...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You have no idea :-)
On top of saving hundred's of GBytes of writes a day, it's even more if you factor in savings on moving unnecessary Data (temp-stuff is "hot" stuff), between SSD/HDD Tiers every night, and than... extend that to savings on your Backups. We're talking over a few Tbytes saved aday. Not bad for getting lightning-fast performance at the user-level in return ;-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Unfortunately, the File/Product Version thing doesn't work...
I script in Powershell, and that adheres to the "windows-way" of looking at File/Product-version:
PS C:> get-item ImDiskTk.exe|fl *
VersionInfo
InternalName:
OriginalFilename:
FileVersion:
FileDescription:
Product:
ProductVersion:
The SFX-Module adds a FileVersion field, but it seems to do it in a different way than Windows itself would...
Fact the field does show in Explorer is apparently due to the SFX-Extension in use. Bummer
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Interesting. I just tested the Win32 functions on ImDiskTk.exe (GetFileVersionInfo and VerQueryValue) and they work properly.
So this means that PowerShell doesn't use these functions. Microsoft doesn't use its own API...
A few more tests show that all the executables compiled with MinGW have this issue. But I see nothing that could help to fix this incompatibility.
Last edit: v77 2017-01-15
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Alright, got it working. This works perfectly for updating ImDiskToolkit. Small thing remains though. Initially, the script doesn't do an update since the software is not installed yet, so instead it then does a silent install. Any chance I can do a silent install with all 3 options (in the first main dialog if you install without /fullsilent) disabled ? The first install now has these enabled, which installs more than I'd like (don't want the users to get the context-option for example)
Thanx again
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Of course I can always add options if there are enough people interested, but for now, you can remove the context options by removing the following registry keys:
2 minor questions:
1) Would it be possible in furture versions to have the installer carry the version in the FileVersion Property ?
This would enable my scripts to auto-detect a newer version and silently install it over the older one.
If it's just a small feat that would be very nice. Thanks
2) Does a dynamicly allocated RamDisk support sparse-files ? They do seem to work properly, but would rather
have an official answer prior to general use.
1) This could be done but... Do you mean that you download the installation package just to know whether it's a newer version?
Various websites are able to publish the new version only a few hours after I uploaded it on SourceForge, so it should be easy. You can simply check for instance if an URL such as https://sourceforge.net/projects/imdisk-toolkit/files/20161204/ exists.
2) What do you mean? For an image file loaded before the volume is mounted, or in a mounted volume?
For an image file, it's not an issue, because the system reconstitutes all the data for an application that is reading the file.
For a sparse file created in the volume, with the TRIM commands, it's the system that decides where are the area to free, so it should be OK.
And with the cleanup function, I don't rely on the size of the files but on the size of the free space.
About data written, this is not filesystem-dependant.
So in any case, I see no problem with the use of sparse files.
Last edit: v77 2016-12-05
1) No. I have scripts which check the version installed right now by checking the Registry (PoSH: (Get-ItemProperty "HKLM:Software\Microsoft\Windows\CurrentVersion\Uninstall\ImDiskApp" -ea:0).DisplayVersion)
From there, my scripts know wether to support Trim and/or Compression. WOuld like to add a routine that checks the FileVersion of the installer ImDiskTK.exe, compares it with above Reg-entry, and initiates a silent install (=update) if the installer is newer. I do this from a controlled folder, in other words, only if I put a newer version in that folder would all scripts on all servers detect that and update automagically. Much better than updating it manually on 100+ servers :-)
Since you use the date as version, and I don't know when you're gonna post a new version (which I want to test beforehand anyway) adding this version/date to the FileVersion Property would enable above scenario for us. Would be nice. Added benefit would be: Now I do this manually, and after startup a RamDIsk is already in place, then updating means the existing RamDisk gets removed, also removing al my Redirection, which is not really what I would prefer :-)). If the startup script could do the above, it would update before a ramdisk actually gets created, thereby eleminating the need for manual labour, losing data from already existing ramdisk, and no need for a reboot on top of that...
Despite its popularity, I never really imagined this tool in this kind of use...
Anyway, I started to work on that.
If you only knew... ;-)
I have many uses for it. Like redirecting the entire Windows Update Engine to a Dynamic RamDisk. All downloads and updating occurs almost entirely in Ram. Same for any of the many processes Windows has that all generate alot of useless I/Os, like Event logs, Event Traces, parts of the CBS engine, Temp Folders of all profiles, including SystemProfile,Local Service, Network Service, etc.
Any writes that can later be discarded get redirected to Ram. On top of doing this in all VMs, doing the same on physical Hyper-V Servers, redirecting VM BIN (Used Memory layouts) and Checkpoints, as they are temporary in nature anyway. This results in unprecedented performance for all kinds of Maintenance like updates, defrags, cleanups, etc. while sacrificing nothing of value at reboot.
Many thankx in advance...
... your SSD's mustve almost eternal life ! ;)
You have no idea :-)
On top of saving hundred's of GBytes of writes a day, it's even more if you factor in savings on moving unnecessary Data (temp-stuff is "hot" stuff), between SSD/HDD Tiers every night, and than... extend that to savings on your Backups. We're talking over a few Tbytes saved aday. Not bad for getting lightning-fast performance at the user-level in return ;-)
Unfortunately, the File/Product Version thing doesn't work...
I script in Powershell, and that adheres to the "windows-way" of looking at File/Product-version:
PS C:> get-item ImDiskTk.exe|fl *
VersionInfo
InternalName:
OriginalFilename:
FileVersion:
FileDescription:
Product:
ProductVersion:
The SFX-Module adds a FileVersion field, but it seems to do it in a different way than Windows itself would...
Fact the field does show in Explorer is apparently due to the SFX-Extension in use. Bummer
Interesting. I just tested the Win32 functions on ImDiskTk.exe (GetFileVersionInfo and VerQueryValue) and they work properly.
So this means that PowerShell doesn't use these functions. Microsoft doesn't use its own API...
A few more tests show that all the executables compiled with MinGW have this issue. But I see nothing that could help to fix this incompatibility.
Last edit: v77 2017-01-15
Hmm... Sometimes PoSH is very easy, sometimes, it's just utterly cumbersome !
Using this, I still get what I want
$objFSO = New-Object -com Scripting.FileSystemObject
$objfso.GetFileVersion("ImDiskTk.exe")
2016.12.31.0
Thankx for implementing this... :-)
Last edit: Wizard 2017-01-15
Alright, got it working. This works perfectly for updating ImDiskToolkit. Small thing remains though. Initially, the script doesn't do an update since the software is not installed yet, so instead it then does a silent install. Any chance I can do a silent install with all 3 options (in the first main dialog if you install without /fullsilent) disabled ? The first install now has these enabled, which installs more than I'd like (don't want the users to get the context-option for example)
Thanx again
Of course I can always add options if there are enough people interested, but for now, you can remove the context options by removing the following registry keys:
Removing the desktop shortcuts is even more easy if you can retrieve the desktop folder of the current user.
Last edit: v77 2017-03-12
Thankx. This will do... :-)