Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (herse.apache.org: domain of wes.garland@gmail.com
 designates 64.233.184.235 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth;
        b=XSngw5M78DRtbLIzD7gWacD7rCRIvHzCjCQVVvkOrko6KpSan9l5ZjW18H7JG2BicH+0AHwRbHnyluAhZhdk8L/XrEPgDvGCqvPFA9ZQm950+Um8sJM7xDli+/JTkjxaWcf7TqpHfa4R2cnXdRcq0xT+pOViW6B+Mi0pICSfL9k=
Message-ID: <be1f08ab0704161031v1b820103i533753833088c7e4@mail.gmail.com>
Date: Mon, 16 Apr 2007 13:31:18 -0400
From: "Wesley W. Garland" <wes@page.ca>
Sender: wes.garland@gmail.com
To: "APR Development List" <dev@apr.apache.org>
Subject: Interesting apr_proc_create() / apr_file_mktemp() interaction
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_46103_30388071.1176744678233"

------=_Part_46103_30388071.1176744678233
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------=_Part_46103_30388071.1176744678233
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

List:<br><br>I found an interesting interaction between apr_proc_create() and apr_file_mktemp() today. I&#39;m not sure if it should be classified as an *actual* bug, or a silly feature which needs to be documented. Consider this snippet:
<br><br><div style="margin-left: 40px;"><span style="font-family: courier new,monospace;">file = apr_file_mktemp();</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">proc = apr_proc_create();
</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">stat(the_filename) = ENOENT.</span><br style="font-family: courier new,monospace;"></div><br>Why?<br><br>The apr_file_t * returned by apr_file_mktemp() is registered in its pool as delete-on-close.&nbsp; apr_proc_create closes all opened files after fork() and before execve() (presumably by destroying the top-level pool? Maybe via atexit()?)
<br><br>Anyhow, the net effect is a really unexpectedly deleted file by the parent process.<br><br>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!
<br><br>FWIW, this is on Solaris 8 / Sparc.&nbsp; The unlink() system call is actually called immediately after the file descriptor closes. Verified using truss -f.<br><br>Which raises another tiny question, shouldn&#39;t the file be unlink()ed *before* it&#39;s close()d?&nbsp; That would unable any apr_file_lock() locks on the file to stay &quot;active&quot; 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.
<br><br>Comments?<br><br>Wes<br><br>-- <br>Wesley W. Garland<br>Director, Product Development<br>PageMail, Inc.<br>+1 613 542 2787 x 102

------=_Part_46103_30388071.1176744678233--