Temp file options

[Rick Brewster]

Here is how it works in v2.2 Alpha 2 and before: files are dumped into %TEMP% with a fairly random filename, and deleted when the object that refers to it in memory is garbage collected, or when the program exits. There is no attempt to clean up the data if the process is terminated, crashes, or there is abnormal system shutdown.

In v2.5 Alpha 3 and later, here is how it works:

1. The files are put into %USERPROFILE%/Local Settings/Application Data/Paint.NET (we actually ask for the special folder, CSIDL_LOCAL_APPDATA).

2. In this directory, we create a folder to hold this session's data. The folder's name is just a random integer value.

3. Inside the directory we createa file named session.lock. It is 0 bytes and created with FILE_FLAG_DELETE_ON_CLOSE and FILE_ATTRIBUTE_TEMPORARY. This file is kept open until PaintDotNet.exe terminates.

4. The session's temporary files (serialized history data, to be precise) are stored in files in this directory. Their names are just random integer values. We create the file, dump data into it, and then close the file. Right now these files are not opened with FILE_ATTRIBUTE_TEMPORARY (not sure how it applies in our case since we are closing the file once we dump the data).

5. These files are deleted when the object in memory that refers to them is garbage collected, or when Paint.NET exits.

But what about if Paint.NET is terminated or crashes ... how are these files cleaned up? Well, when you start Paint.NET it enumerates the other session directories. If there is a file called session.lock in the directory and it cannot open it (i.e. it's still open by another instance of Paint.NET), then it leaves the directory alone. Otherwise it wipes it out.

It would be a bad idea to open each of these temporary files with FILE_FLAG_DELETE_ON_CLOSE because then we'd be required to keep an open file handle to every single one of them for the lifetime of the Paint.NET session. That could easily add up and we'd be consuming a lot of resources. How hard is it to imagine someone with a history that goes back 100 items? 1000? 10,000? It could happen, and would end up being an artificial limitation.

Also, it would not handle the cleanup case if the system is abnormally shut down. FILE_FLAG_ON_DELETE doesn't help you there, I believe (or maybe NTFS does some crazy bookkeeping, it's possible). That's why we clean-up on session startup as well.