[Issue 13996] New: Function for returning a temporary file with a randomly generated name where the name can be accessed
via Digitalmars-d-bugs
digitalmars-d-bugs at puremagic.com
Sat Jan 17 14:57:08 PST 2015
https://issues.dlang.org/show_bug.cgi?id=13996
Issue ID: 13996
Summary: Function for returning a temporary file with a
randomly generated name where the name can be accessed
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: Phobos
Assignee: nobody at puremagic.com
Reporter: issues.dlang at jmdavisProg.com
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.
--
More information about the Digitalmars-d-bugs
mailing list