You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The FRF contains logic such that if a folder exists in the package and the app tries to create a sub item (file or folder) then the item will be created in the local appdata "writablepackageroot" area. Under investigation is a potential issue for when the folder in the package is specifically the VFS folder.
For example, the package has the folder "VFS\ProgramFilexX64\Vendorname", but not "VFS\AppData". Currently it looks as if with this setup if the app attempts to create "%AppData%/vendorfolder", the FRF kicks in and creates this in the writablepackageroot (The app first opens %AppData%, which is adding VFS/AppData folder to the writable package root, and then the subfolder is created under it). While this would be desirable if there had been an AppData folder in the package, in the absence of it we would probably want the native write to occur. Likewise, other folders like LocalAppData and CommonAppData should probably also be adjusted.
Without the FRF in place (to solve problems with the ProgramFiles area), this app would have just written the files natively. Or maybe natively depending on the OS Runtime (which is why this needs more investigation) I think that the FRF should do the same as such files may need access.
While it would be possible to construct json rules to avoid this from happening, my preference is to allow one standard set of rules to work for most all applications that need the FRF.
The text was updated successfully, but these errors were encountered:
The FRF contains logic such that if a folder exists in the package and the app tries to create a sub item (file or folder) then the item will be created in the local appdata "writablepackageroot" area. Under investigation is a potential issue for when the folder in the package is specifically the VFS folder.
For example, the package has the folder "VFS\ProgramFilexX64\Vendorname", but not "VFS\AppData". Currently it looks as if with this setup if the app attempts to create "%AppData%/vendorfolder", the FRF kicks in and creates this in the writablepackageroot (The app first opens %AppData%, which is adding VFS/AppData folder to the writable package root, and then the subfolder is created under it). While this would be desirable if there had been an AppData folder in the package, in the absence of it we would probably want the native write to occur. Likewise, other folders like LocalAppData and CommonAppData should probably also be adjusted.
Without the FRF in place (to solve problems with the ProgramFiles area), this app would have just written the files natively. Or maybe natively depending on the OS Runtime (which is why this needs more investigation) I think that the FRF should do the same as such files may need access.
While it would be possible to construct json rules to avoid this from happening, my preference is to allow one standard set of rules to work for most all applications that need the FRF.
The text was updated successfully, but these errors were encountered: