apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@covalent.net>
Subject Re: apr_file_mktemp
Date Sun, 30 Sep 2001 22:57:49 GMT
On Sunday 30 September 2001 12:56 pm, Cliff Woolley wrote:
>    I was fixing Apache's htdigest to use apr_file_mktemp() instead of
> tmpnam() and ran into a small snafu.  apr_file_mktemp() goes ahead and
> unlinks the temporary file after it's open and before returning to the
> caller.  htdigest currently assumes that it it has the ability to
> system("cp ...") the temporary file over top of the old passwd file.  But
> since the temp file is already unlinked, the cp fails of course.  All I
> can think of given this design is to reopen the main password file and
> rewrite it line by line, reading from the still-open apr_file_t* which is
> our only reference to the temp file.
>    But I'm unclear as to whether apr_file_mktemp() unlinking the temporary
> file is actually the correct behavior.  The file is opened as
> APR_DELONCLOSE, so the call to apr_file_remove() should be and is handled
> by apr_file_close() when necessary.  As is, we're deleting the file twice.
> SUSv2 doesn't seem to say whether or not mkstemp() should unlink the file
> or not.
>    Oh, PS, I'm not sure if we care about this, but the function might want
> to be called apr_file_mkstemp(), since on Unix mktemp() just returns the
> filename, not a file descriptor.  mkstemp() is what does that.

I unlinked the file because that allowed things to work on Unix.  The 
DELONCLOSE on Unix doesn't unlink at close time, it does it by unlinking
as soon as the file is opened.  That may be a bug.  The function name is
deliberately not the same as POSIX, because I really don't like the name
mkstemp.  :-)

We are making a temp file.  I think the name expresses that well.


Ryan Bloom				rbb@apache.org
Covalent Technologies			rbb@covalent.net

View raw message