Can a UWP app change files in another app's AppData folder if using broadFileSystemAccess and runFullTrust?

Question

I have a C# Windows Form app that does something (roughly) like:

1. OpenFileDialog() <-- points to a file path
2. File.Exists() <-- confirms the file path is valid
3. File.GetLastWriteTime() <-- checks the file's last modified time
4. ZipArchive.CreateEntryFromFile() <-- creates new zip if file has changed

I'm trying to get the app working as a UWP app. I have successfully gotten it compiled to an APPX and it installs/launches fine. However it seems like all file activity it handles is stuck in a cached/sandbox version of the file system or something.

For example:

• I select a C:\\Temp\\hello.txt in the app (step #1 above)
• Then I modify the text file it in notepad, save and exit
• Then I trigger my app to execute steps #3 and #4
• However step #3 claims the file has not changed. This is what makes me think the UWP app is looking at a cached or sandbox set of my filesystem? Or something else odd happening here?
• Additionally, if I try to force the app to make the zip regardless of the last modified date, no zip file is actually created when I check the folder - again this makes me wonder if the app is stuck in some sandbox/cache of my file system not the actual file system?
• (New) Another interesting clue here is that if I open a Windows Explorer window to C:\\Temp I can see my hello.txt file by itself. If I open the openFileDialog() in the UWP app to C:\\Temp I can see my hello.txt file and the hello.zip file it created. So both windows are using C:\\Temp but they show different files!?

Other Notes:

• UWP app is being created via desktop bridge (makeappx.exe)
• My AppManifest.xml does have the appropriate broadFileSystemAccess and runFullTrust capabilities declared.
• I have set the app to be allowed file system access in the File System Privacy Settings dialog in Windows 10.
• The app works perfectly fine when running as an class *.exe (not a UWP/Appx)

Answer 1

The desktop bridge capture and redirects file writes to folders that are part of the package. You can read more about this in the official docs . The purpose is to allow the operating system to clean up those files when the app is uninstalled.

You should be able to write to a folder that is not part of the package as long as the user has access to this folder though, and you should then be able to see the file in this actual folder in the File Explorer.