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

Mime
View raw message