httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Hay <steve....@uk.radan.com>
Subject Re: [RELEASE CANDIDATE] libapreq2 2.08-RC4
Date Tue, 25 Jul 2006 09:24:35 GMT
Randy Kobes wrote:
> On Mon, 24 Jul 2006, Steve Hay wrote:
> 
>> Randy Kobes wrote:
>>
>>> Also, just to verify that it is the stray temp files
>>> left over that are causing the problem, does it help
>>> if you change the APR_EXCL flag in the call to apr_file_mktemp on 
>>> about line 832 of library/util.c
>>> to APR_TRUNCATE?
>> Yep, that makes the errors go away: it didn't fail once in about two 
>> dozen runs.
> 
> Does the following help?
[...]
> 
> With the APR_SHARELOCK flag, I don't see any temp files
> left over after about 50 runs of the upload.t test (without
> it, but still with APR_FILE_NOCLEANUP, I would have 2-3
> left over after 50 runs).

Yes, that works for me!  I tried the individual test and the whole test 
suite dozens of times over and didn't get a single failure.

I'm not sure how it makes any difference, though, or exactly what it 
does.  I searched the whole of my httpd-2.2.2 folder and only found one 
use of it (actually, of its new name, APR_FOPEN_SHARELOCK) relating to 
sdbm files.  What am I missing?

Is the change safe, or does it introduce any security issues with 
temporary spool files being shared somehow?

-- 


------------------------------------------------
Radan Computational Ltd.

The information contained in this message and any files transmitted with it are confidential
and intended for the addressee(s) only. If you have received this message in error or there
are any problems, please notify the sender immediately. The unauthorized use, disclosure,
copying or alteration of this message is strictly forbidden. Note that any views or opinions
presented in this email are solely those of the author and do not necessarily represent those
of Radan Computational Ltd. The recipient(s) of this message should check it and any attached
files for viruses: Radan Computational will accept no liability for any damage caused by any
virus transmitted by this email.
Mime
View raw message