List: 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. Why? 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. Comments? Wes -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102
