httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe+gm...@sunstarsys.com>
Subject Re: apreqXXXXXX temp files remain after processing uploads greater than 256kb. Further large upload fails
Date Sun, 11 Mar 2007 20:42:26 GMT
Joe Schaefer <joe+gmane@sunstarsys.com> writes:

> Randy Kobes <randy@theoryx5.uwinnipeg.ca> writes:

[...]

>> Removing the APR_FILE_NOCLEANUP would, I think, bring
>> us back to the problem described at
>>    http://marc.theaimsgroup.com/?t=115337629400001&r=1&w=2
>> for which this was introduced, in that some Win32 systems
>> have occasional stray temp files lingering around.
>
> May I suggest that people start posting version numbers of
> both libapr and operating system?  All we're doing now is 
> running around blindly tweaking crap that we really 
> shouldn't be tweaking in the first place.

Apologies for the tone of that,  I don't mean to sound so
discouraging.  Let me try to offer a suggestion for how
we might deal with this constructively.

The problem, as far as I can tell, stems from the fact
that apr uses the win32 api for some things, and the 
posix api for others.  On Windows those are two entirely
different subsystems, with varying levels of quality
depending on which version of Windows you are running.

So I think what's happening in the cases where the
tempfiles aren't being removed is that the call to
apr_file_remove is failing.  On windows, let's trap
that error in apreq_file_cleanup and call DeleteFile()
in that case.  If that fails return APR_EGENERAL.
Also, get rid of this ifdef in apreq_file_mktemp:

#ifdef WIN32
    flag |= APR_FILE_NOCLEANUP | APR_SHARELOCK;
#endif

It's bogus, and IMO is only confusing the situation.

-- 
Joe Schaefer


Mime
View raw message