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 snippet:

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 atexit()?)

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

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 erase!

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

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 NON-BLOCKING mode.



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