> > Question: Is the use of O_TEMPORARY to open() portable? (my
> win32 docs
> > say it will make the file automatically deleted when the last
> > descriptor is closed, which I didn't know before. That
> would make the
> > patch much simpler, but might require #ifdefs?)
>
> I think it would be more elegant if you wrote a replacement
> implementation of
> tmpfile() for pgport and did not change pg_dump at all.
> And/or write a bug to Microsoft about a buggy C library.

It's not buggy. It's well documented behaviour,and per my linux manpage
for the file it's also OK per spec:

The standard does not specify the directory that tmpfile()
will use. Glibc will try the path prefix P_tmpdir defined
in <stdio.h>, and if that fails the directory /tmp.


It's certainly *stupid*, but not buggy ;-)

//Magnus

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Am Donnerstag, 20. April 2006 13:21 schrieb Magnus Hagander:
> It's not buggy. It's well documented behaviour,and per my linux manpage
> for the file it's also OK per spec:
>
> The standard does not specify the directory that tmpfile()
> will use. Glibc will try the path prefix P_tmpdir defined
> in <stdio.h>, and if that fails the directory /tmp.

The spec says

The tmpfile() function shall create a temporary file and open a
corresponding stream. The file shall be automatically deleted when all
references to the file are closed. The file is opened as in fopen() for
update (w+).

If the implementation is such that it tries to create the file in a directory
that the user does not have write permission to, it's a bug.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Peter Eisentraut <peter_e@gmx.net> writes:
> If the implementation is such that it tries to create the file in a directory
> that the user does not have write permission to, it's a bug.

Well, I think it would be a valid implementation on Unix to always try
to create the file in /tmp, which'd likely fail if someone had revoked
world write on /tmp --- but doing the latter is administrator error,
not a library fault.

OTOH, if / is *supposed* to be non world writable on Win32, then trying
to create temp files there indicates a seriously brain-damaged library.
It should be trying to create the file in a place where the user is
expected to have permission to do it.

Has anyone looked to see with tmpfile() actually does though? I'm a bit
surprised that it doesn't create stuff in the same directory as tmpnam().
I wonder if Magnus and Yoshiyuki are testing under different conditions.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster