Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FileRedirectionFixup and "other" VFS folders. #157

Open
TimMangan opened this issue Sep 22, 2020 · 0 comments
Open

FileRedirectionFixup and "other" VFS folders. #157

TimMangan opened this issue Sep 22, 2020 · 0 comments

Comments

@TimMangan
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant