using NamedTemporaryFile on windows

**Peter Hansen** · Dec 29 '05, 05:55 AM

Re: using NamedTemporaryF ile on windows

Lee Harr wrote:[color=blue]
> 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 NamedTemporaryF ile:
>
> """
> 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)
> """[/color]

As it says, if you *don't close* the file, you can open it again if you
are on a platform which supports that.
[color=blue][color=green]
>>From looking through the code, the NamedTemporaryF ile will be[/color]
> deleted as soon as it is closed.
>
> So... if I can't open it again why does it need a name?[/color]

Because you can open it again *if* you don't close it... but not on Windows.
[color=blue]
> Is there a way on windows to make a tempfile that I can open again?[/color]

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().
[color=blue]
> Maybe what I need is just mkstemp, since that also returns a name?
> If so, what is the point of NamedTemporaryF ile?[/color]

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

NamedTemporaryF ile 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 NamedTemporaryF ile
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** · Dec 29 '05, 10:35 PM

Re: using NamedTemporaryF ile on windows

On 2005-12-29, Peter Hansen <peter@engcorp. com> wrote:[color=blue]
> Lee Harr wrote:[color=green]
>> Is there any other reason to use a named tempfile other than
>> to be able to open it again?[/color][/color]
[color=blue]
> As it says, if you *don't close* the file, you can open it again if you
> are on a platform which supports that.
>[/color]

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.

[color=blue]
> NamedTemporaryF ile 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 NamedTemporaryF ile
> 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).
>[/color]

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** · Dec 29 '05, 10:55 PM

Re: using NamedTemporaryF ile on windows

On Thu, Dec 29, 2005 at 12:40:34AM -0500, Peter Hansen wrote:[color=blue]
>
> What I don't understand is why you _can't_ reopen the NamedTemporaryF ile
> 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).[/color]

Basically the only reason that you want a NamedTemporaryF ile 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** · Dec 30 '05, 05:15 AM

Re: using NamedTemporaryF ile on windows

Lee Harr wrote:[color=blue]
> On 2005-12-29, Peter Hansen <peter@engcorp. com> wrote:[color=green]
>>What I don't understand is why you _can't_ reopen the NamedTemporaryF ile
>>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).[/color]
>
> Are you saying you tried it and you actually can do what it says
> you can't do?[/color]

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 NamedTemporaryF ile 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** · Dec 30 '05, 05:45 AM

Re: using NamedTemporaryF ile on windows

[Peter Hansen][color=blue][color=green][color=darkred]
>>> What I don't understand is why you _can't_ reopen the NamedTemporaryF ile
>>> 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).[/color][/color][/color]

[Lee Harr][color=blue][color=green]
>> Are you saying you tried it and you actually can do what it says
>> you can't do?[/color][/color]

[Peter Hansen][color=blue]
> 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. ;-)[/color]

Because NamedTemporaryF ile 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
NamedTemporaryF ile 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.

using NamedTemporaryFile on windows

using NamedTemporaryFile on windows

Comment

Comment

Comment

Comment

Comment