Writing to package AppData results in broken permissions

[yoshiask]

Describe the bug

Attempting to write to the packaged app data directory using System.IO or StorageFile from a packaged WinUI 3 Desktop app causes unusual permissions issues. Any files or directories created will have the Archive | Encrypted attributes, despite being neither an archive nor encrypted. Programmatically copying the files into a different, non-AppData directory of course doesn't solve the issue (the file is still "encrypted").

Steps to reproduce the bug

1. Clone https://github.com/yoshiask/Repros
2. Observe the code in https://github.com/yoshiask/Repros/blob/47570dee79bd80c853be778da66eb36eae726caf/WinAppSdk/WinAppSdk/MainWindow.xaml.cs
3. Run the WinAppSdk (Package) project and look at the debug console output.

or

1. Create a new packaged WinUI 3 project
2. Use ApplicationData.Current.LocalFolder.Path to get the packaged app data directory
3. Use File.WriteAllText or StorageFile.CreateFileAsync to write to a file in that directory
4. Observe that the file attributes are Archive | Encrypted

Expected behavior

Successfully read and write to the packaged app data directory.

Screenshots

No response

NuGet package version

1.1.3, 1.1.2

Packaging type

Packaged (MSIX)

Windows version

Windows 11 version 21H2 (22000), Windows 10 version 21H2 (19044, November 2021 Update), Windows 10 version 21H1 (19043, May 2021 Update)

IDE

Visual Studio 2022-preview, Visual Studio 2022

Additional context

This issue effectively means apps can't write to app data at all. File system virtualization for the app data directory is enabled by default for packaged apps, which means even trying to write to %appdata% directly gets redirected to the packaged app data directory. The only workaround I could find (apart from just not writing to App Data) is to disable virtualization, but App Installer refuses to install any package that declares the unvirtualizedResources rescap.

As a side note, my app also declares the packageQuery and packageManagement rescaps. Why does App Installer care that my app can write to the real App Data, but not that it can install any arbitrary package to the user's system? Seems pretty arbitrary to me, but that's a separate problem.

[DrusTheAxe]

As a side note, my app also declares the packageQuery and packageManagement rescaps. Why does App Installer care that my app can write to the real App Data, but not that it can install any arbitrary package to the user's system? Seems pretty arbitrary to me, but that's a separate problem.

That's due to different decisions/policies regarding i/o virtualization vs package management (not defending or attacking the policies, just stating the facts). If you'd like to discuss it further please open a new Discussion thread.

[riverar]

@yoshiask Hm, I can't reproduce this on 25163 or 22000.795. Are you using any kind of disk middleware that could be touching the files during the trip to disk?

[yoshiask]

@riverar There really can't be anything, I thought it was virtualized resources causing problems but even using StorageFile directly doesn't work. I was able to reproduce this on my own machine and a friend's with the debugger, and many of my app's users were experiencing crashes related to this issue.

I believe ShareX ran into the same bug a while back as well.

[alexlamtest]

@yoshiask - Regarding “Observe that the file attributes are Archive | Encrypted” • First, the Archive attribute is expected. You can navigate to %localappdata%\packages and pick another existing app, say AppZ, that has a file under its LocalState folder and examine its attributes to convince yourself. • As long as AppZ is installed on the System Drive (C:), I expect the file to not have the Encrypted attribute set. • Now if you use the Settings->Apps->Installed Apps->{ AppZ }->Move UI to move AppZ to a non-System Drive, the LocalState folder should turn into a symbolic link (free up the app's files/folders before the move). If you follow that link to find the same file and check its attribute again, it is now expected to have the Encrypted attribute set. (I’ve verified this on my machine).

• In case AppZ wouldn’t let you move it to a non-System Drive, you should be able to find another app, say AppY, that would let you move it. In case AppY does not have a file under its LocalState folder, you can do a “dir > %localAppData%\packages\< AppY >\LocalState\myTest.txt” to create a dummy test file for experimentation. Just remember to delete it after you’re done.

• IOW, the Encrypted attribute is generally unexpected for a file under an AppData folder when it’s on the System Drive but is expected when the app is on a non-System Drive. That’s the baseline I’d like to establish, and it's not specific to WinAppSDK. • If you get the Encrypted attribute for your app even when it is on the System Drive, then:

• If you manually do a “dir > %localAppData%\packages\< YourOwnApp >\LocalState\myTest.txt”, does it have the Encrypted attribute?
• If you repeat the above with another existing app, do you also get the Encrypted attribute? If no, then your app might have AppData encryption accidentally enabled?
• If the answer to the above 2 bullets are both “yes”, then I’d repeat the test with “dir > %localAppData%\packages\myTest.txt” and see what happens. Perhaps someone else enabled encryption on a large part of your file system.

I hope these steps can help narrow this down, please let us know what you find out.

[alexlamtest]

@yoshiask - I'm wondering whether this issue is still impacting you, and if so, what further info you can supply to fuel further investigations?

[alexlamtest]

@yoshiask - is there any update? Investigation of this issue has been blocked for a while due to the lack of diagnostic information. I suggest we close this issue as "not planned" if investigation remain blocked for another week or so.

[alexlamtest]

Closing this issue due to lack of diagnostic info.