I have my temp folder on an imdisk ramdisk G: and with new Firefox 83 downloading any file and directly opening it (open with...) fails.
I don't know the specifics but I suppose it's maybe a bug, or more probably a new security feature ?
I'm saying that because the command "fsutil fsinfo ntfsInfo G:" results in an error "not a local volume" as opposed to a softperfect ramdisk image that it (as do Firefox) accepts.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No problem for me. I am using Firefox 83 and with the TEMP folder on a ramdisk, Firefox can use "Open with". And I checked that the file is present on the Ramdisk (R:\Temp).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for checking.
There's more to it, I used the default value %USERPROFILE%\AppData\Local\Temp for %temp% and made a symbolic link from there to the ramdisk.
And it appears that FF is ignoring %temp%, using AppData\Local\Temp instead for "open with", even creating it if absent. Software like that are the very reason I used the symbolic link.
The problem remains that this setup was working with FF 82 + imdisk and now with 83 it's not, whereas none of the issue happens with softperfect.
The easy workaround is to delete the link AppData\Local\Temp and use G:\temp as %temp%, until I run into my former issue.
Last edit: bud 2020-11-20
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I didn't try, but Firefox cannot create AppData\Local\Temp if it is a symbolic link, unless it first deletes the symbolic link, and then creates the folder.
And it cannot hardlink to this folder because the full path changes depending on the name of the user account.
Even the Windows API uses the TEMP/TMP variables (by the way, don't forget to set both).
Anyway, if you don't want to change the default value of the TEMP/TMP variables for the whole system, you also can change them in a batch file that calls then Firefox. For most softwares, including Firefox, there is no difference.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't know, this is really confusing because I have been testing, doing fresh reboots in between and seeing different results where it should be consistent as we would believe.
Alright then, somehow when using an imdisk ramdisk and the symbolic link, FF is "detecting" that the temp folder is not a regular folder and stops operations.
Using a batch file works, thank you for that.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have my temp folder on an imdisk ramdisk G: and with new Firefox 83 downloading any file and directly opening it (open with...) fails.
I don't know the specifics but I suppose it's maybe a bug, or more probably a new security feature ?
I'm saying that because the command "fsutil fsinfo ntfsInfo G:" results in an error "not a local volume" as opposed to a softperfect ramdisk image that it (as do Firefox) accepts.
No problem for me. I am using Firefox 83 and with the TEMP folder on a ramdisk, Firefox can use "Open with". And I checked that the file is present on the Ramdisk (R:\Temp).
Thank you for checking.
There's more to it, I used the default value %USERPROFILE%\AppData\Local\Temp for %temp% and made a symbolic link from there to the ramdisk.
And it appears that FF is ignoring %temp%, using AppData\Local\Temp instead for "open with", even creating it if absent. Software like that are the very reason I used the symbolic link.
The problem remains that this setup was working with FF 82 + imdisk and now with 83 it's not, whereas none of the issue happens with softperfect.
The easy workaround is to delete the link AppData\Local\Temp and use G:\temp as %temp%, until I run into my former issue.
Last edit: bud 2020-11-20
I didn't try, but Firefox cannot create AppData\Local\Temp if it is a symbolic link, unless it first deletes the symbolic link, and then creates the folder.
And it cannot hardlink to this folder because the full path changes depending on the name of the user account.
Even the Windows API uses the TEMP/TMP variables (by the way, don't forget to set both).
Anyway, if you don't want to change the default value of the TEMP/TMP variables for the whole system, you also can change them in a batch file that calls then Firefox. For most softwares, including Firefox, there is no difference.
I don't know, this is really confusing because I have been testing, doing fresh reboots in between and seeing different results where it should be consistent as we would believe.
Alright then, somehow when using an imdisk ramdisk and the symbolic link, FF is "detecting" that the temp folder is not a regular folder and stops operations.
Using a batch file works, thank you for that.
You should run RamDisk Configuration Tool with administrator privilegies