`tempname` creates file on Windows but not on *NIX

As noted by @tkelman. tempname on Windows does not mean the same thing that it means on *NIX. For *NIX, the relevant docs state that; "The tmpnam() and tempnam() functions return a pointer to a file name on success, and a null pointer on error", while on Windows; "Creates a name for a temporary file. If a unique file name is generated, an empty file is created and the handle to it is released; otherwise, only a file name is generated". Should we accept this discrepancy as a part of our API?

[tkelman]

Pretty sure the discrepancy is in tempname, not mktemp, since on unix the Julia mktemp function ccalls posix mkstemp

The mkstemp() function makes the same replacement to the template and creates the template file, mode 0600, returning a file descriptor opened for reading and writing. This avoids the race between testing for a file's existence and opening it for use.

@tkelman: Thanks, spotted it as I was changing it. =)

I would probably vote for redefining tempname as:

function tempname()
    (f, io) = mktemp()
    close(io)
    f
end

The only problem being that it renders tempname rather useless in comparison to mktemp.

It should also be noted that the documentation currently is at least misleading for Windows.

[tkelman]

I like how http://man7.org/linux/man-pages/man3/tempnam.3.html says

Never use this function. Use mkstemp(3) or tmpfile(3) instead.

That might be a vote for deprecating tempname. It looks like the only thing we might lose in that case would be the Windows-only uunique input, I'll have to look at MSDN again to figure out what that does.

[nalimilan]

+1 for deprecation unless there's a good use case for not using mktemp.

If tempfile gets deprecated and Windows does not provide a good API for it, a stop-gap can be to simply generate a random number and use that for the file name.

[tkelman]

Opinions, @johnmyleswhite and/or @vtjnash? According to blame it looks like you did most of the writing and rewriting of these functions.

I think I will side with the deprecation camp. Even if we agree on tempname creating a file and returning only the filename, the function name would be very misleading.

[vtjnash]

the windows API (like the linux API) is entirely in userspace. it's fine to emulate the whole thing. the windows api creates (and closes) the file to help with the race condition issue mentioned above (and because it uses sequential search for a filename, rather than whatever it is that <insert name of your favorite *nix> does)

while tempnam is not recommended, there are applications that require you to pass a filename, rather than a file handle, in which case it is essential.

while tempnam is not recommended, there are applications that require you to pass a filename, rather than a file handle, in which case it is essential.

@vtjnash: I can certainly see those use-cases. If so, would you consider this solution for *NIX to be satisfactory? Also, would you agree that tempname is a rather poor name for a function that in fact creates a file?

[nalimilan]

@vtjnash Yet Python has deprecated mktemp and has a very bold warning in the docs:
https://docs.python.org/3.4/library/tempfile.html#tempfile.mktemp

If the function is really needed we should add the same warning in the docs.

@ninjin The name of the function comes from the Unix system call, I agree it's not great. mktemp like Python is not great either since the mk evokes creating the file to me.

[vtjnash]

@nalimilan we don't differentiate between mktemp and mkstemp, so we don't suffer from the same issue as python's mktemp

[nalimilan]

@vtjnash What do you mean? tempname cannot be made completely secure because there's a race condition between the time you check the file does not exist and the time you create it. The only secure API is to directly create the file a return a handler.

I think the following questions should summarise the discussion so far:

1. Do we agree that it is not desirable that tempname behaves differently depending on the platform?
2. If so, do we agree that, following the same argument as for mktemp, the current behaviour on Windows should be the default? That is, creating the file.
3. If so, do we agree that if a function creates a file and returns the path to it, tempname is a poor name?
4. If so, and we choose to keep the functionality, what should the new name of the function be?

I would answer as follows:

1. Yes, it is our duty to have a portable unified API.
2. Yes, safety should be the default.
3. Yes, the current name would be very confusing.
4. How about mktempname? It preserves the similarity to the previous name, while making clear that it creates something.