Create temporary files and folders

[Semphriss]

Description

This PR adds three new functions to create temporary files and folders:

SDL_IOStream *SDL_SYS_CreateSafeTempFile(void)
char *SDL_SYS_CreateUnsafeTempFile(void)
char *SDL_SYS_CreateTempFolder(void)

The difference between the "safe" and "unsafe" versions of creating a temporary file is because using paths opens the door to timing attacks, including (but not only) time-of-check-to-time-of-use (TOCTOU). For any purpose requiring security, paths should not be used, but since temporary paths are sometimes needed more than security, I've included the unsafe version as well.

Currently, only Unix has an implementation.

Existing Issue(s)

Closes #10841

[slime73]

What are the cross-platform guarantees about their lifetimes (including when the app crashes rather than gracefully closes)?

[Semphriss]

For the SDL API, I haven't made any guarantee, since I'm not familiar enough (yet, at least) with what guarantees are provided by other systems to decide which ones are reasonable to apply to SDL.

In the specific case of Unix:

• SDL_SYS_CreateSafeTempFile: Uses tmpfile under the hood, for which my man page says: "The file will be automatically deleted when it is closed or the program terminates." tmpfile(3)
• SDL_SYS_CreateUnsafeTempFile: Uses mkstemp under the hood. The man page does not say anything, but experimentation shows that on my system, the file survives termination of the parent.
• SDL_SYS_CreateTempFolder: Uses mkdtemp under the hood; same implications as above.

[slime73]

What I've read in the past is that Windows doesn't really have safe/possible cleanup of temporary data if an app crashes, so that's what I'm worried about I guess if people start relying on it. Especially if people create unique temporary paths which would then fill up a user's HD.

I'd also want to know how the lifetimes behave on mobile platforms, where users are not encouraged to quit apps themselves.

[slime73]

SDL_SYS_CreateUnsafeTempFile: Uses mkstemp under the hood. The man page does not say anything, but experimentation shows that on my system, the file survives termination of the parent.

Maybe it could be named to indicate that the file will be unique but not temporary? The name feels kind of misleading as-is.

[Semphriss]

Maybe it could be named to indicate that the file will be unique but not temporary? The name feels kind of misleading as-is.

I've named it "temp" because that's how systems chose to name the concept (tmpfile, mkstemp, /tmp, C:\Users\Someone\AppData\Local\Temp, GetTempFileName, GetTempPath, etc). I think it's named "temporary" as in "This file's usage will be temporary [and does not need to persist on the disk like other files]", not as in "This file's existence must be kept as temporary as possible"; the system decides when the temporary files are deleted, most often with a reboot or on user request.

[slime73]

Yeah, historical naming of those lower level APIs have temp in the name - it's just pretty confusing to me as a user to have an API with the name 'temporary' that creates something which isn't temporary and requires the caller to clean it up manually. Especially when it's right next to another API with the name 'temporary' that creates something which is supposedly truly temporary. IMO SDL shouldn't be required to follow the naming of POSIX APIs here.

Or alternatively, what sort of use cases do temporary files that aren't automatically cleaned up have which aren't as feasible with a regular file?

[Semphriss]

I'm not sure how exclusively historical the naming is, given that additions as recent as 2008 are still named with "temp" without any additional note in the documentation. It's also not exclusive to POSIX; the same concept is used at least on Windows. As for SDL_CreateSafeTempFile, the files do not need to be deleted simply as a side effect of not having any path that could be passed to SDL_RemovePath. None of the mechanisms other than this one have any builtin auto-deletion-on-close, although that doesn't make them permanent either; the system is always the one that takes care of deleting the files, probably on a reboot. Additionally, all systems I could check on have a "Delete all temporary files" button.

One notable use case where temporary files would be needed without holding open file descriptors on every temporary file for their entire lifetime would be pretty much any scenario involving SDL_CreateTempFolder (which cannot have a similar lifetime bound to an open fd, and is therefore inherently "unsafe" in that sense). For example, extracting a downloaded archive file to use its contents, AppImage-style but not necessarily just for executables, would require preserving the directory trees for the contents of the archive, and should preferably not require holding up to several thousand open file handles simultaneously, which would be resource-consuming and is often subject to system-imposed restrictions (ulimit -n).

Another use case is temporary files that must be used by multiple processes.

I wouldn't necessarily oppose a better naming, but I'm concerned about people who already are familiar with temporary files in the current definition, and who would be confused when seeing a different naming. If the name is to be changed, I would recommend double-checking that the change is more beneficial than confusing.

[Semphriss]

The Unix implementation should work across all Unix-likes, including Haiku, macOS, POSIX, and so on; how should I handle this? Should I copy-paste the code, or add another file for it?

[slouken]

The Unix implementation should work across all Unix-likes, including Haiku, macOS, POSIX, and so on; how should I handle this? Should I copy-paste the code, or add another file for it?

Like the process subsystem, you can create a windows folder and a posix folder and all the UNIX-likes can use that.