0

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)
Christopher
  • 1,639
  • 19
  • 22
  • 1
    Is it a pure UWP app or a desktop bridge app, i.e. did you package your existing WinForms app or did you actually converted it to UWP? Where do you save the file? In a pure UWP app, the `broadFileSystemAccess` capability works only for the `Windows.Storage` APIs. – mm8 Apr 03 '19 at 13:34
  • Thanks for chiming in. Well 1) the exe/manifest files are converted to an appx installer via makeappx.exe - and I install it as a Win10 UWP that way. And 2) the file the app looks at (specified by the user via openFileDialog) could be anywhere on the file system (C:\*.*, D:\*.* etc). – Christopher Apr 03 '19 at 14:00
  • 1
    So it seems like you are using the desktop bridge. You should then be able to save files to C:\Temp\. Are you getting any runtime exceptions when you try to save the file or what happens? – mm8 Apr 03 '19 at 14:04
  • No exceptions no. I just noticed something new though. 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!? – Christopher Apr 03 '19 at 14:31
  • 1
    @ChrisEmerson As mm8 said, the `broadFileSystemAccess` capability only works for [Windows.Storage APIs](https://msdn.microsoft.com/library/windows/apps/BR227346). What you used `File.Exists()`, `File.GetLastWriteTime()` etc are all not included in the 'Windows.Storage'. – Xie Steven Apr 04 '19 at 06:08
  • @XavierXie-MSFT Thanks for the comment. So even when a UWP app is using `runFullTrust` the app is not able to truly lookup/get info about files from the actual file system (like C:\Temp\hello.txt)? Or are you saying if I drop `broadFileSystemAccess` the `runFullTrust` will take over and allow me to process the actual file system? – Christopher Apr 04 '19 at 09:14
  • 1
    @ChrisEmerson: A packaged desktop app is able to lookup and write files in c:\temp. Are you writing to the actual c:\temp folder or are you writing to a system folder like c:\windows? – mm8 Apr 04 '19 at 11:20
  • 1
    Can you look for your file under: "C:\Users\\AppData\Local\Packages\\LocalCache" ? That is where usually redirected resources end up. – Bogdan Mitrache Apr 04 '19 at 14:15
  • @BogdanMitrache you were right! Files that *appeared* to be C:\temp\hello.txt in my UWP app were actually coming from \appdata\Local\Packages! Is there a way around this so the app uses the actual C:\temp\hello.txt? – Christopher Apr 04 '19 at 19:43
  • @mm8 Well my app is a C# exe converted to an APPX via makeappx.exe and installed as a Windows 10 app. Is there a different path I could take to get my C# exe to a Windows 10 app that would lookup and write files directly in the actual file system vs the AppData\Local\Packages area? – Christopher Apr 04 '19 at 19:45

1 Answers1

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.

mm8
  • 163,881
  • 10
  • 57
  • 88
  • Thanks for this mm8. I tested things again based on your comments and found the issue (I think). When I have my UWP app look at files in C:\Temp\Folder\test.txt everything works fine (as you point out). However when I have my app look at C:\Users\Administrator\AppData\Roaming\RandomApp\test.txt things do not work and my app seems to see/use a hidden/copy of that folder so any changes made to test.txt by the file system are ignored by my app. Is there something special about files in AppData folders for UWP apps to work with? – Christopher May 18 '19 at 15:50
  • 1
    @ChrisEmerson: Yes, it is. Please refer to the link I posted. – mm8 May 20 '19 at 13:05
  • That link was very helpful as it describes my core problem: Unable for UAP app to change files in another app's AppData folder. I guess the bottom line answer is No ... I can't do this (even with "broadFileSystemAccess"). Very frustrating. Thank you (and everyone else) for your help. I'll update the question with a more accurate title. – Christopher May 20 '19 at 18:42