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
+1 613 542 2787 x 102