using NamedTemporaryFile on windows

[Lee Harr]

Is there any other reason to use a named tempfile other than
to be able to open it again? I am trying to understand this
section of the documentation regarding NamedTemporaryFile:


"""
Whether the name can be used to open the file a second time, while the named temporary file
is still open, varies across platforms (it can be so used on Unix; it cannot on Windows NT
or later)
"""


From looking through the code, the NamedTemporaryFile will be
deleted as soon as it is closed.

So... if I can't open it again why does it need a name?

Is there a way on windows to make a tempfile that I can open again?

Maybe what I need is just mkstemp, since that also returns a name?
If so, what is the point of NamedTemporaryFile?

 

[Peter Hansen]

Is there any other reason to use a named tempfile other than
to be able to open it again? I am trying to understand this
section of the documentation regarding NamedTemporaryFile:

"""
Whether the name can be used to open the file a second time, while the named temporary file
is still open, varies across platforms (it can be so used on Unix; it cannot on Windows NT
or later)
"""

As it says, if you *don't close* the file, you can open it again if you
are on a platform which supports that.

deleted as soon as it is closed.

So... if I can't open it again why does it need a name?

Because you can open it again *if* you don't close it... but not on Windows.

Is there a way on windows to make a tempfile that I can open again?

Do you mean open again without having closed it (in other words,
basically get two different file handles to the same open file)? That's
apparently exactly what you cannot do on Windows, as noted above.

Do you mean a file that you can open again *later*, after having closed
it? If so, you obviously don't want a file that is automatically
deleted when you close it, so you just want mkstemp().

Maybe what I need is just mkstemp, since that also returns a name?
If so, what is the point of NamedTemporaryFile?

It creates a file that can be reopened under Unix provided you haven't
closed it yet. ;-)

NamedTemporaryFile doesn't appear to have much purpose on Windows, but
that's more or less what the docs already say. I think the only thing
you were missing perhaps was this idea of "opening a file a second time"
*without having closed it first*.

What I don't understand is why you _can't_ reopen the NamedTemporaryFile
under Windows when you can reopen the file created by mkstemp (and the
files created by TemporaryFile are created by mkstemp in the first place).

-Peter

 

[Lee Harr]

As it says, if you *don't close* the file, you can open it again if you
are on a platform which supports that.

Ok. I just started wondering if maybe there was some other reason,
like stat()ing the file, or taking a picture of Elvis pointing at
it in a directory listing or something.

NamedTemporaryFile doesn't appear to have much purpose on Windows, but
that's more or less what the docs already say. I think the only thing
you were missing perhaps was this idea of "opening a file a second time"
*without having closed it first*.

What I don't understand is why you _can't_ reopen the NamedTemporaryFile
under Windows when you can reopen the file created by mkstemp (and the
files created by TemporaryFile are created by mkstemp in the first place).

Are you saying you tried it and you actually can do what it says
you can't do?

I don't have any windows system to test this, but I want to write
some code that will work on windows. I'm just going to use mkstemp.

Thanks for your time.

 

[Chris Lambacher]

What I don't understand is why you _can't_ reopen the NamedTemporaryFile
under Windows when you can reopen the file created by mkstemp (and the
files created by TemporaryFile are created by mkstemp in the first place).

Basically the only reason that you want a NamedTemporaryFile is so that you
can write something to a file, tell another process to use that file (that you
have just written to) and then have file cleanup taken care of for you
automatically. This works on Unix where you can have process open a
file for reading while another process has the file open for writing. You
can't do this on Windows without jumping through a lot of hoops(sqlite and MS
Access come to mind as programs that manage this, though they may start a
server process to manage it).

mkstemp does create a file for you, but you are responsible for removing the
file when you are done. Unfortunately this is what you are left with on
Windows.

-Chris

 

[Peter Hansen]

Are you saying you tried it and you actually can do what it says
you can't do?

I don't think so. I think I was saying that I can do exactly what it
says I can, and can't do what it says I can't do, but that I don't
understand why there is a difference between the two approaches given
what else it says... (I hope that's clearer than it looks to me. ;-)

I did try it, and I can't reopen the NamedTemporaryFile on Windows, but
I can reopen the mkstemp file. Both from the same process, which could
be quite different than what the docs are actually talking about (noting
Chris' reply).

-Peter

 

[Tim Peters]

[Peter Hansen]
[Lee Harr]
[Peter Hansen]

I don't think so. I think I was saying that I can do exactly what it
says I can, and can't do what it says I can't do, but that I don't
understand why there is a difference between the two approaches given
what else it says... (I hope that's clearer than it looks to me. ;-)

Because NamedTemporaryFile on Windows passes the Microsoft-specific
O_TEMPORARY flag, and mkstemp doesn't. One consequence is that you
have to delete a temp file obtained from mkstemp yourself, but a
NamedTemporaryFile goes away by magic when the last handle to it is
closed. Microsoft's I/O libraries do that cleanup, not Python.

Another consequence is that a file opened with O_TEMPORARY can't be
opened again (at least not via C stdio), not even by the process that
opened it to begin with. AFAICT Microsoft never documented this, but
that's how it works. Because you can't delete an open file on
Windows, temp files on Windows always have names visible in the
filesystem, and that's a potential "security risk". _Presumably_ the
inability to open an O_TEMPORARY file again was a partially-baked
approach to eliminating that risk.