Joe Schaefer <[EMAIL PROTECTED]> writes: > Randy Kobes <[EMAIL PROTECTED]> 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
