Lately, not sure when, but at least the last 4 updates on Windows 10 1809, Ramdisk fails to be configured or to write registry values, I have to configure Ramdisk manually through windows registery.
An I am not able to install msi files from the Ramdisk, it will tell that access denied, or can't find the device or the specified file. No problem installing exe files from the Ramdisk, or installing msi files directly from the 2 hard disks, SSD or HDD.
No issues on windows 7
Anyone else has these issues on Windows 10?
Last edit: paradis pal 2019-03-03
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Beware that MS also changed the servicing stack quite a bit. For example: You can't have the SoftwareDistribution\Download folder in RamDisk anymore since 1809 because in an effort to speed up installing Updates (which actually works quite well in speeding up) Microsoft now will download, unpack and then hardlink the content directly from the Download-folder. You can't hardlink from one disk (RamDisk) to another disk (OS), so for me I had to let go of that idea sadly...
Last edit: Wizard 2019-03-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've also had the occasional problem where an app wouldn't install if TEMP and TMP were set to a folder on the RAM disk. This only seems to happen with msiexec, and I'm not sure if it's recent changes in the OS or not but I definitely didn't have those problems 6 months ago.
The installers were quite small and it definitely wasn't a space issue. I assume it's permissions, hardlinks or something similar as mentioned above.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I refrain from settting TEMP and TMP environment variables to other than default locations, because there are installers/programs as mentioned here that simply assume the default locations without checking any further. To prevent that kind of issues but still redirect those folders, I replace the original folder locations with symbolic links to the new location. That way, you are fooling the OS, and thus also any installer/program that the default locations are "actually" someplace else. In other words, using symbolic links is completely transparent to any OS/program running on top of it. DOwnside is also that because of that, that same program/installer might be checking available diskspace for example for drive C: which has enough free, but because of the transparent redirection to for example a drive D: (the ramdisk) which doesn't have enough space, that doesn't get checked, so the nistaller then proceeds assuming there's enough space free while actually on the RamDIsk there isn't. There's nothing you can do about that other than making sure the RamDisk is big enough or using the trick I mentioned in the previous thread for Virtual Machines, or keeping track of that yourself before running the installer...
If you don't have the RamDisk mounted as a Drive but as a mountpoint, you can easily check available free space on the RamDisk using this command from a command prompt:
(Assuming you have the RamDIsk on mountpoint C:\RamDisk)
fsutil.exe volume diskfree C:\RamDisk
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
PS:
If you're on Windows 10 1809 or Server 2019, make sure to have this latest update https://support.microsoft.com/en-us/help/4489899
which solves an issue with certain MSI/MSP installers:
* Addresses an issue that may cause users to receive “Error 1309” while installing or uninstalling certain types of MSI and MSP files.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You should use mklink /d <folder> <redirected location=""> instead of mklink /j.
/j creates a Junction while /d creates a Symbolic link. The former is NOT completely OS transparent while the latter is.</redirected></folder>
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It is windows defender, controlled folder access, I turned it off and no problems. Microsoft should white-list imdisk!
The other issue, happens only during startup. The ramdisk will not mount, but I will ba able to mount it manully. Windows defender is disabled on that machine. and it is windows 1809.
This started happening in the last few updates, and not the main upgrade to 1809!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Lately, not sure when, but at least the last 4 updates on Windows 10 1809, Ramdisk fails to be configured or to write registry values, I have to configure Ramdisk manually through windows registery.
An I am not able to install msi files from the Ramdisk, it will tell that access denied, or can't find the device or the specified file. No problem installing exe files from the Ramdisk, or installing msi files directly from the 2 hard disks, SSD or HDD.
No issues on windows 7
Anyone else has these issues on Windows 10?
Last edit: paradis pal 2019-03-03
My bad, I edited the permissions of the folder C:\windows\servicing in my 2 rigs, and it was the reason.
No problem. It would have been surprising, as the writes in the registry are done in a very standard way.
Beware that MS also changed the servicing stack quite a bit. For example: You can't have the SoftwareDistribution\Download folder in RamDisk anymore since 1809 because in an effort to speed up installing Updates (which actually works quite well in speeding up) Microsoft now will download, unpack and then hardlink the content directly from the Download-folder. You can't hardlink from one disk (RamDisk) to another disk (OS), so for me I had to let go of that idea sadly...
Last edit: Wizard 2019-03-07
I've also had the occasional problem where an app wouldn't install if TEMP and TMP were set to a folder on the RAM disk. This only seems to happen with msiexec, and I'm not sure if it's recent changes in the OS or not but I definitely didn't have those problems 6 months ago.
The installers were quite small and it definitely wasn't a space issue. I assume it's permissions, hardlinks or something similar as mentioned above.
I had the same issue but forgot to write it!
I did a clean install in a virual machine, Imdisk workled fine, edit the permission of the folder and I had the same problem.
It maybe more, I do play a lot with my windows folders, registery values, do scripts.
The piont is Imdisk worked fine in a clean installed windows 1809, even the insider preview slow build 18342.8 no issues.
I refrain from settting TEMP and TMP environment variables to other than default locations, because there are installers/programs as mentioned here that simply assume the default locations without checking any further. To prevent that kind of issues but still redirect those folders, I replace the original folder locations with symbolic links to the new location. That way, you are fooling the OS, and thus also any installer/program that the default locations are "actually" someplace else. In other words, using symbolic links is completely transparent to any OS/program running on top of it. DOwnside is also that because of that, that same program/installer might be checking available diskspace for example for drive C: which has enough free, but because of the transparent redirection to for example a drive D: (the ramdisk) which doesn't have enough space, that doesn't get checked, so the nistaller then proceeds assuming there's enough space free while actually on the RamDIsk there isn't. There's nothing you can do about that other than making sure the RamDisk is big enough or using the trick I mentioned in the previous thread for Virtual Machines, or keeping track of that yourself before running the installer...
If you don't have the RamDisk mounted as a Drive but as a mountpoint, you can easily check available free space on the RamDisk using this command from a command prompt:
(Assuming you have the RamDIsk on mountpoint C:\RamDisk)
fsutil.exe volume diskfree C:\RamDisk
It works. Thank you.
I use mklink to create directory junction from D:, run: mklink /J temp z:\temp
and set TMP/TEMP to D:\temp
PS:
If you're on Windows 10 1809 or Server 2019, make sure to have this latest update
https://support.microsoft.com/en-us/help/4489899
which solves an issue with certain MSI/MSP installers:
* Addresses an issue that may cause users to receive “Error 1309” while installing or uninstalling certain types of MSI and MSP files.
I installed KB4489899 on Windows 10 1809
I still get error when TMP/TEMP set to Ramdisk
You should use mklink /d <folder> <redirected location=""> instead of mklink /j.
/j creates a Junction while /d creates a Symbolic link. The former is NOT completely OS transparent while the latter is.</redirected></folder>
Another thing I also forget to write about.
Sometimes, not always, starting windows will not mount the Ram-Disk. I have to restart again to mount the Ram-disk, or to mount it manually.
Anyone else with issue?
Again it happens only with the last few update on windows 1809. Not the main update 1809, just the last few cumulative updates.
When it happens, did you try to restart Explorer?
This way, we could know whether it's (again) a notification issue or something else.
Maybe I addressed one cause of the issue in one machine runnign windows insider 18356.1
https://imgur.com/a/HpjJMp3
It is windows defender, controlled folder access, I turned it off and no problems. Microsoft should white-list imdisk!
The other issue, happens only during startup. The ramdisk will not mount, but I will ba able to mount it manully. Windows defender is disabled on that machine. and it is windows 1809.
This started happening in the last few updates, and not the main upgrade to 1809!