apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wesley W. Garland" <...@page.ca>
Subject Interesting apr_proc_create() / apr_file_mktemp() interaction
Date Mon, 16 Apr 2007 17:31:18 GMT

I found an interesting interaction between apr_proc_create() and
apr_file_mktemp() today. I'm not sure if it should be classified as an
*actual* bug, or a silly feature which needs to be documented. Consider this

file = apr_file_mktemp();
proc = apr_proc_create();
stat(the_filename) = ENOENT.


The apr_file_t * returned by apr_file_mktemp() is registered in its pool as
delete-on-close.  apr_proc_create closes all opened files after fork() and
before execve() (presumably by destroying the top-level pool? Maybe via

Anyhow, the net effect is a really unexpectedly deleted file by the parent

How did I find this? I was using an apr_file_mktemp() file to schedule a job
with at. By the time at ran, the file with the commands to schedule had been

FWIW, this is on Solaris 8 / Sparc.  The unlink() system call is actually
called immediately after the file descriptor closes. Verified using truss

Which raises another tiny question, shouldn't the file be unlink()ed
*before* it's close()d?  That would unable any apr_file_lock() locks on the
file to stay "active" until it was gone, meaning that no other process could
touch it.. at least, another process that uses advisory file locking in



Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102

View raw message