Bug 13996 – Function for returning a temporary file with a randomly generated name where the name can be accessed
Status
RESOLVED
Resolution
FIXED
Severity
enhancement
Priority
P1
Component
phobos
Product
D
Version
D2
Platform
All
OS
All
Creation time
2015-01-17T22:57:00Z
Last change time
2017-07-19T17:42:54Z
Assigned to
nobody
Creator
issues.dlang
Comments
Comment #0 by issues.dlang — 2015-01-17T22:57:08Z
We need a function which creates a file with a temporary name where we have access to the name and can close and reopen the file. We have std.stdio.tmpfile, which calls the C tmpfile function and gives us a temporary file, but we have no access to the name of the file, and it gets deleted when its closed, which is completely useless for many situations, especially in unit tests where you need to do something like write to a file, close it, and then read from it.
POSIX's mkstemp does something similar to this, but on some systems, it doesn't allow for very many file names (e.g. the windows implementation is restricted to 26; some POSIX implementations have similar limitations), and it doesn't provide any control over where the file is written to.
So, I propose that we create something like
static File tempFile(string prefix = "", string dir = tempDir()) {...}
in std.stdio.File which allows for adding a prefix like mkstemp does but also allows control over where the file goes and does not have the same limitations on the number of randomly generated files as mkstemp sometimes does. And, of course, it's a normal File which won't delete itself when being closed, so it will be able to be used like any other File, unlike the one returned by std.stdio.File.tmpfile.
And with that added, I'd suggest that we deprecate tmpfile, since IMHO it's pretty useless, and it'll reduce confusion if there's only one function returns a temporary file with a randomly generated name, but that's obviously up for debate.
(In reply to Martin Nowak from comment #1)
> You forgot suffix argument :).
What suffix? As suggested, it takes an optional prefix and randomly generates the rest. You mean that it should take an extension? Or do you think that it should take a suffix rather than a prefix? I suppose that if it takes a suffix rather than a prefix, the extension could just be part of the suffix.
> It's missing for ages, we just needed it for dub
> https://github.com/D-Programming-Language/dub/pull/497#issuecomment-72763326.
>
> The python implementation takes a reasonable approach, generate random names
> and try to exclusively open the file.
>
> https://github.com/python/cpython/blob/
> 1196330dedbe741f8a0c418abcd2956fad29837f/Lib/tempfile.py#L191
>
> The new function could be called namedTempFile. It's still useful to have a
> tempFile function that directly unlink the file.
I have a working implementation for Linux. The problem is that I can't figure out how to get _wsopen or any of its relatives to work on Windows. The linker fails to find them, even when I verify that they're in snn.lib (or whatever the name of the library is with the stdio stuff in it that comes with dmc). So, I'm not quite sure what to do. I could easily create a PR, but it's kind of pointless if it doesn't work on Windows.
As for keeping tmpfile, I suppose that we could - to avoid forcing anyone to change their code if nothing else - but in my experience, the function is utterly useless. And replacing it with tempFile would be trivial. instead of
auto file
Comment #3 by issues.dlang — 2015-02-04T00:23:31Z
Drat. I managed to post by accident. In any case, tmpfile could easily be replaced such that
auto file = File.tmpfile();
became
auto file = File.tempFile();
scope(exit) std.file.remove(file.name);
so IMHO tmpfile becomes redundant on top of being pretty useless. But it _does_ mean deprecating it if we're getting rid of it, so it might be better to just keep it around rather than dealing with that.
Comment #4 by code — 2015-02-04T02:17:43Z
(In reply to Jonathan M Davis from comment #3)
> auto file = File.tempFile();
> scope(exit) std.file.remove(file.name);
There is a security aspect, because the current tempfile is unlinked at the moment it's created. So no other process can access it.
But as that's the advanced use-case it deserves the longer name, anonTempFile or so.
Comment #5 by code — 2015-02-04T02:21:54Z
> What suffix? As suggested, it takes an optional prefix and randomly generates the rest. You mean that it should take an extension?
Yes, prefix and suffix, random in between.
Comment #14 by issues.dlang — 2015-07-26T21:08:35Z
(In reply to Timothee Cour from comment #13)
> the pull seems to cause this regression:
> https://issues.dlang.org/show_bug.cgi?id=14828
I'm not sure how it could be, since it was reverted. Maybe the changes for scratchFile triggered that bug, were reverted, and now something later is triggering it. I don't know. But since the changes for this were already reverted, it's not like we can revert them to fix the regression.
Comment #15 by github-bugzilla — 2017-07-19T17:42:54Z