> > 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.
Prior to Windows XP, users had write permissions in the root IIRC. They
definitly had in NT4, but I think they did in 2000 as well.
> 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.
I have repeated the problem with CVS head on XP SP2. It *does* create it
there (or rather, it tries to).
tmpnam() returns a file in the current dir per documentation, but I see
it generating one in the root instead.
tempnam() uses TMP environment variable.
tmpfile() and tmpnam() both use the same function to generate the
filename.
//Magnus
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
