Are the folders in AppDataPaths always guaranteed to exist, and also why is there no equivalent of ApplicationData.Current.TemporaryFolder?

[benstevens48]

I'm using a packaged app. I'm wondering if the paths given by AppDataPaths.GetDefault() are always guaranteed to exist on disk? I assume so but I can't find it explicitly documented anywhere. Also, why is it missing the equivalent of certain folders from ApplicationData like ApplicationData.Current.TemporaryFolder?

[T (cookesan)]

For the path-string API, I would still create the directory before first use:

Directory.CreateDirectory(appDataPaths.LocalAppData);

Directory.CreateDirectory is idempotent, so it is a cheap way to make the write path robust even if a specific folder has not been materialized yet.

For a closer WinRT-style replacement, check the newer Windows App SDK storage API rather than only AppDataPaths. Microsoft.Windows.Storage.ApplicationData.GetDefault() exposes folder/path properties including local and temporary app data in current SDKs. If your target Windows App SDK version has TemporaryFolder / TemporaryPath, that is the equivalent you are looking for.

[Howard Kapustein (DrusTheAxe)]

One final interesting point. If you delete the app package's TempState folder (probably applies to any of the package's app data folders), it is not recreated, even if you access it via ApplicationData.GetDefault().TemporaryFolder.Path.

ByDesign. ApplicationData's runtime codepaths don't auto-heal, 'cause, reasons (see below). But you can fix them, if/when necessary (also see below).

PS C:\Foo> Add-AppxPackage c:\foo\hello.msix

PS C:\Foo> $(get-appxpackage hello).packagefullname
hello_0.0.0.0_neutral__8wekyb3d8bbwe
PS C:\Foo> Get-ChildItem ${env:LocalAppData}\Packages\hello_8wekyb3d8bbwe

        Directory: C:\Users\neo\AppData\Local\Packages\hello_8wekyb3d8bbwe


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d----          1/2/2025   8:32 AM                  AC
d----          8/4/2021  12:25 AM                  AppData
d----          8/4/2021  12:25 AM                  LocalCache
d----          8/4/2021  12:25 AM                  LocalState
d----          8/4/2021  12:25 AM                  RoamingState
d----          1/2/2025   8:32 AM                  Settings
d----          8/4/2021  12:25 AM                  SystemAppData
d----          8/4/2021  12:25 AM                  TempState

PS C:\Foo>  Remove-Item -Path C:\Users\neo\AppData\Local\Packages\hello_8wekyb3d8bbwe
PS C:\Foo> Get-ChildItem ${env:LocalAppData}\Packages\hello_8wekyb3d8bbwe

        Directory: C:\Users\neo\AppData\Local\Packages\hello_8wekyb3d8bbwe


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d----          1/2/2025   8:32 AM                  AC
d----          8/4/2021  12:25 AM                  AppData
d----          8/4/2021  12:25 AM                  LocalCache
d----          8/4/2021  12:25 AM                  LocalState
d----          8/4/2021  12:25 AM                  RoamingState
d----          1/2/2025   8:32 AM                  Settings
d----          8/4/2021  12:25 AM                  SystemAppData

PS C:\Foo>  Add-AppxPackage -RegisterByFamilyName -MainPackage hello_8wekyb3d8bbwe
PS C:\Foo> Get-ChildItem ${env:LocalAppData}\Packages\hello_8wekyb3d8bbwe

        Directory: C:\Users\neo\AppData\Local\Packages\hello_8wekyb3d8bbwe


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d----          1/2/2025   8:32 AM                  AC
d----          8/4/2021  12:25 AM                  AppData
d----          8/4/2021  12:25 AM                  LocalCache
d----          8/4/2021  12:25 AM                  LocalState
d----          8/4/2021  12:25 AM                  RoamingState
d----          1/2/2025   8:32 AM                  Settings
d----          8/4/2021  12:25 AM                  SystemAppData
d----          8/4/2021  12:25 AM                  TempState

TL;DR Add the package, remove the TempState directory, register the package and poof! It's back

This is ByDesign. ApplicationData.GetDefault() is common runtime path and "broken ApplicationData data store structure" is a very rare bird, thus adding auto-breakage-detection would be common runtime overhead for a very rare event. Thus merely using AppData doesn't kick in any self-healing logic.

The classic advice when something's wrong with Windows (or most any other electronics): "Did you reboot?" For MSIX it's bit more of a 3-step checklist

1. Did you quit the app and restart?
2. Did you reboot?
3. Did you re-register the package?

Some problems (e.g. ERROR_SHARING_VIOLATION) are due to running processes holding resources blocking activity. In that case ending process(es) can release the resources, and of course rebooting is the ultimate process termination. For more durable problems the common answer is "re-register the package". The deployment pipeline follows the motto

'Tis not the journey that matters, only the destination

Re-registering a package will run thru the various steps in the deployment pipeline. On first install that means doing work (create directories, etc). If a package is already known to the system then registration becomes more of a "I need directory X to exist. Make it so if necessary" -- if the directory doesn't exist, create it (like 1st time install), and if it does exist then MissionAccomplished suuuuper fast.

That's why ApplicationData doesn't automagically fix broken persistent resources, and why there's no ApplicationData.RepairAsync() -- there is, but it's called PackageManager.Register*Async*() :-)

[Howard Kapustein (DrusTheAxe)]

GetTempPath() returns the classic shared temp folder for the user. And it turns out that writing into this is not redirected to the app package's TempState folder

Nope. If you're a Centennial process then I/O Virtualization should virtualize those writes; you'd need to look at the package's VFS for the physical write/storage. If you're not (or you are but I/O Virtualization is disabled) you'd write to the classic location (%USERPROFILE%\AppData\Local\Temp), unless you're an AppContainer process then writes go to ...\AC\Temp (AC is a peer of TempState).

I suspect in the I/O Virtualization is enabled AND an AppContainer process scenario, AC beats I/O Virtualization. But take with grain of salt; I don't know, didn't work on that plumbing, and it was complicated enough it's not something casually picked up.

There were reasons I don't entirely understand why AC\Temp was chosen rather than TempState, and at this point it's kinda moot as any change would pose compat issues. There'd need to be a really compelling reason to go there, so I doubt it'll ever happen.

(also GetTempPath2)

No surprise there. GetTempPath2 is a slight variant so it works (securely) for LocalSystem callers. It's effectively

IF thread impersonation
    token = OpenThreadToken()
ELSE
    token = OpenProcessToken()
ENDIF
ti = GetTokenInformation(token, TOKEN_USER)
IF ti.User == CreateWellKnownSid(LocalSystem)
    path = %windir%\Temp
ELSE
    return GetTempPath()
ENDIF

However it is consistently 50% slower to copy a JPEG file into this folder than into the app package's TempState folder, for some unknown reason.

Now that's interesting.

Copy how? CopyFile(from="c:\foo\bar.txt", to=GetTempPath() + "\bar.txt") vs ...to=ApplicationData.GetDefault().TemporaryFolder.Path...?

Also, most of the initial time penalty for accessing Windows.Storage.ApplicationData.Current.LocalFolder is paid by accessing any folder off Windows.Storage.ApplicationData.Current. Then subsequent access to other folders is in the order of 1ms.

Could be the StorageFolder tax. We've got paths as strings, then turn into StorageFolder objects, 'cause, API surface. ApplicationData really should have *Path properties like *Folder but just return the string without going thru the StorageFolder rigamarole (similar to how Windows.ApplicationModel.Package has *Path properties for each *Folder). That's what the optimization will do.

So, anyway, a way to get the app package's temp folder path without using Windows.Storage.ApplicationData.Current.TemporaryFolder would be useful!

I hear you. Time, time, time...

[Howard Kapustein (DrusTheAxe)]

P.S. Speaking of ApplicationData you may find this useful

https://github.com/DrusTheAxe/AppData

Created way back (Win81?) out of personal need and occasionally updated since.

Hmmm. Looks like I should update to .NET 10. I've been meaning to add .7z support for a while so... :-)

[benstevens48]

Thanks for the reply!

Copy how?: yes, correct except the paths were got outside of the timing interval.
If you're a Centennial process then I/O Virtualization should virtualize those writes: so actually what I mean was that even for a packaged desktop app, files written to %USERPROFILE%\AppData\Local\Temp do actually end up in %USERPROFILE%\AppData\Local\Temp (looking via Explorer). Given the performance difference, maybe the write is virtualized, but the virtualization actually doesn't do anything (files end up in same classic folder), so seems unnecessary. Anyway, I prefer using an app-specific folder for clean uninstall.
Could be the StorageFolder tax: yes but accessing a different folder off ApplicationData.Current also speeds up subsequent access to other folders (although possibly all the StorageFolders are created at once internally).

[Howard Kapustein (DrusTheAxe)]

(although possibly all the StorageFolders are created at once internally).

No, the instances are created on demand. But the SF plumbing being 'warmed up' may be a factor (DLLs loaded, data initialized, etc).

I prefer using an app-specific folder for clean uninstall.

Always a good idea :-)