Why would one ever use the %TEMP% folder now that Storage Sense can clean it at any time?

Question

Starting with Windows 10, Storage Sense has allowed users to specify %TEMP% folder cleanup that are as frequent as once a day. Technically it can run even more often is set to activate on low disk space, depending on one's disk usage patterns.

In light of that, what is the point of the %TEMP% folder? How would I ever use a folder where every file I put there can technically be removed by the system the moment after I finish writing it?

Here is a real world scenario where this hit me (code simplified for brevity):

var ffmpegPath = Path.Combine(Path.GetTempPath(), "ffmpeg");
DownloadFfmpeg(path: ffmpegPath); 

foreach (var videoFile in videoFiles) { //suppose there are dozens of files to process
   DoSomeHeavyProcessing(ffmpegPath);   //suppose each file takes an hour to process
}

This worked great for the first few hours, but then at some arbitrary point in time the downloaded ffmpeg folder was deleted and all the subsequent files could not be processed. In fact, if I understand correctly, in theory even code like this could fail:

var path = Path.Combine(Path.GetTempPath(), "foo");
File.WriteAllText(path, "bar");
Console.WriteLine(File.ReadAllText(path));

Now, I know how to solve this - simply use %APPDATA%, %LOCALAPPDATA% or %PROGRAMDATA%. But that's the point - since the advent of Storage Sense, why would I ever use %TEMP% rather than the former folders?

Methylnaphthalene

There's also LocalCacheFolder. See docs and stackoverflow.com/a/23461912 – Recognize

Answer 1

The %TEMP% folder is -- as the name suggests -- for temporary files, which are only needed for a (typically short) period of time and can be deleted afterwards. In an ideal world, every app writing to the temp folder would clean up afterwards and delete the temporary files it created, when they are not needed any longer. But that does not happen, thus %TEMP% folders tend to become huge.

You can easily prevent Storage Sense from deleting files you still need by acquiring a file lock on that files. As long as a file in the %TEMP% folder is in use, it won't be deleted. Once processing the file has completed, you can free the file lock, which means you won't need the file any more and it can be deleted in the next run of Storage Sense.

This has the advantage, that your app doesn't need to clean up the "mess" (i.e temporary files) anymore. Just have the app lock them as long as they are needed. After the lock is freed (or the app exits, which will also free the file locks), they will automatically get deleted by the system.

Trestle

Upvoted, but I have a few reservations: (1) The file could technically be deleted before I manage to acquire the lock (2) For some reason I might not have permissions to lock files (3) Admittedly the last 2 are unlikely to happen but the more files I download, the higher the chance (e.g. the ffmpeg sample above could have many dlls) (4) I might not be able to lock the files as I'd want other programs to use them (e.g. I lock some ffmpeg config file and ffmpeg fails to run because of it) - yes I could unlock and the relock every time but that's more hassle and more potential for exceptions – Methylnaphthalene

In addition, It's not guaranteed that Storage Sense would run at all (maybe the user disabled it, in fact I think it's off by default). And even when it does, it's not guaranteed if and when my files would get deleted. So practically it feels like I'm keeping all the responsibilities of cleanup, while having to prepare and code for for all the potential pitfalls of auto cleanup. Honestly just saving to something like %APPDATA% with a finally block that cleans up after (or even FileOptions.DeleteOnClose if I really want to be a good Samaritan) seems much simpler. – Methylnaphthalene

your line of argumentation is based on the low-disk-space behaviour. When this bites you within seconds of the file being created, then your system is in serious trouble anyway. In such an emergency situation you can't rely on anything. On the other hand if you react in time, e.g. when disk space gets below 5%, then you're fine. – Jube