httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Hay <>
Subject Re: apreqXXXXXX temp files remain after processing uploads greater than 256kb. Further large upload fails
Date Wed, 14 Mar 2007 18:08:26 GMT
Randy Kobes wrote:
> On Fri, 9 Mar 2007, Joe Schaefer wrote:
>> Randy, do you know why we use the APR_FILE_NOCLEANUP flag?  Maybe
>> we should just remove that and see if it fixes the problem Vinay
>> is seeing.
> Hi Steve, and all,
>  If you remember from
> there was a problem with stray temp files in apreq
> remaining after uploads; we came up with a fix that
> worked most of the time, but Vinay has come up with
> something that appears better, and more understandable.
> The attached diff against library/util.c (in the svn
> sources) works for me in getting multiple invocations
> of the glue/perl/t/apreq/upload.t to pass; if you have
> time, could you try it out to see how it fares on
> your system? Thanks.

I tried your patch with the current svn version (revision 518242), but 
I'm still seeing intermittent failures (usually in tests 15, 16 and/or 
20) either when I run "nmake test" from the top-level, or when I run:

perl -Iblib/arch -Iblib/lib t/TEST -verbose=1 t/apreq/upload.t

from the glue/perl sub-directory :-(

I'm running perl-5.8.8, apache-2.2.2 and mod_perl-2.0.3 (RC3, I think). 
  Do I need to update anything there?


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.
View raw message