Functions for getting temporary filenames/directories (without creating them)?

[hasufell]

All the functions in this package already create said files/directories. This might not be desired, e.g. when the temp filename is the destination of an atomic move operation.

[Fuuzetsu]

I may be wrong, but I don't think such an operation is present as some sort of system primitive. There's the old buggy mktemp function which says "Never use mktemp()". Then there's mkstemp which is what you're supposed to use and which creates a file.

This might not be desired, e.g. when the temp filename is the destination of an atomic move operation.

I think the usual way to solve this is to make a temporary directory (say, via withTempDirectory) and then put a file with some deterministic file name in there. This gives whatever is expecting the file a way to see it "atomically" while ensuring there's no race condition.

I don't think that what you are after is possible to implement without some OS support that tracks temporary file names that it dished out and I don't think such a thing exists.

[hasufell]

I may be wrong, but I don't think such an operation is present as some sort of system primitive. There's the old buggy mktemp function which says "Never use mktemp()". Then there's mkstemp which is what you're supposed to use and which creates a file.

I disagree. If you have a secure directory, there's nothing wrong with mktemp (to create e.g. FIFO files). See also https://unix.stackexchange.com/a/614823

This might not be desired, e.g. when the temp filename is the destination of an atomic move operation.

I think the usual way to solve this is to make a temporary directory (say, via withTempDirectory) and then put a file with some deterministic file name in there. This gives whatever is expecting the file a way to see it "atomically" while ensuring there's no race condition.

That's a pretty odd workaround. Currently I create a temp file and immediately delete it afterwards, reusing the filename.

But yeah, I'm not sure how a cross platform solution would look like. And in fact, I need this on windows, not unix.

I don't think that what you are after is possible to implement without some OS support that tracks temporary file names that it dished out and I don't think such a thing exists.

[UnkindPartition]

I think it'd be fine to add these functions (with the documentation explaining the security implications of using them).

@hasufell would you like to prepare a PR?

[hasufell]

The right place might even be base, since it holds the logic of finding an available filename: https://hackage.haskell.org/package/base-4.15.0.0/docs/src/System-IO.html#openTempFile

[Fuuzetsu]

I disagree. If you have a secure directory, there's nothing wrong with mktemp (to create e.g. FIFO files). See also https://unix.stackexchange.com/a/614823

Not sure which part you're disagreeing about. The docs very explicitly say:

Never use mktemp().

If you have a secure directory

Well, didn't I suggest exactly that? withTempDirectory to get a "secure" (and unique!) directory and you're free to do whatever you want in here without worrying about some other thread coming in and stomping all over your file.

That's a pretty odd workaround. Currently I create a temp file and immediately delete it afterwards, reusing the filename.

Doesn't that let any other call to mkstemp re-use the file name? If not then the implementation is trivial (just do exactly this). If it can re-use the file name then it's not much better than making random names, checking the FS for presence and using it which is just a one huge race condition waiting to explode.

[Fuuzetsu]

I think it'd be fine to add these functions (with the documentation explaining the security implications of using them).

Why? It's fundamentally broken. If the user wants something that's broken, they should just implement it themselves explicitly. It is very simple to do so. If it was complex but very useful, I would potentially agree that there would be a place for it somewhere with some scary name and documentation. It is however simple and of questionable use (it is equivalent to "give me random string that's a filename, check if it's on disk") and alternative proper solutions already exist.

[hasufell]

I disagree. If you have a secure directory, there's nothing wrong with mktemp (to create e.g. FIFO files). See also https://unix.stackexchange.com/a/614823

Not sure which part you're disagreeing about. The docs very explicitly say:

Never use mktemp().

If you read the link I gave, you can see that POSIX maintainers disagree with you and have declared their willingness to accept a patch adding mktemp to the standard.

If you have a secure directory

Well, didn't I suggest exactly that? withTempDirectory to get a "secure" (and unique!) directory and you're free to do whatever you want in here without worrying about some other thread coming in and stomping all over your file.

No you didn't. Secure directory doesn't mean "random directory". This is about random files in a safe place your process controls.

That's a pretty odd workaround. Currently I create a temp file and immediately delete it afterwards, reusing the filename.

Doesn't that let any other call to mkstemp re-use the file name? If not then the implementation is trivial (just do exactly this). If it can re-use the file name then it's not much better than making random names, checking the FS for presence and using it which is just a one huge race condition waiting to explode.

Don't babysit users. The filesystem is a shared resource, half of the functions in directory are non-atomic. base can leak file handles etc etc.

Yes, you have to read the documentation.

[Fuuzetsu]

Don't babysit users.

I'm not trying to. I'm trying to not add stuff to the API that's broken majority of the time.

The only babysitting happening is addition of this basically trivial function for no good reason.

The filesystem is a shared resource, half of the functions in directory are non-atomic. base can leak file handles etc etc.

"Other things are broken so let's make it even worse"?