Re: [RELEASE CANDIDATE] libapreq2 2.08-RC4
Randy Kobes <[email protected]>
| Newsgroups | gmane.comp.apache.apreq |
|---|---|
| Message-ID | <[email protected]> |
On Tue, 25 Jul 2006, Randy Kobes wrote: > On Tue, 25 Jul 2006, Steve Hay wrote: > >> 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? > > I'm baffled now, too - as far as I can see too, apr > only uses APR_FOPEN_SHARELOCK in sdbm files, and neither > mod_perl nor librapreq2 seems to use it. But it does > make a difference - although I don't see as many > failures as you do, without APR_FOPEN_SHARELOCK I > definitely get temp files left over. > >> Is the change safe, or does it introduce any security issues with temporary >> spool files being shared somehow? > > That I'm not sure of, especially now that I'm not sure > what it's affecting ... I still haven't been able to track down why the use of APR_FOPEN_SHARELOCK works in cleaning up the temp files. I did try a simple C apr-based program that just opens a temp file in the same way as is done within apreq_file_mktemp(), with the registered apreq_file_cleanup(), writes some random text to it, and then closes it - in this the temp files were cleaned up with or without APR_FOPEN_SHARELOCK, and also with or without APR_FILE_NOCLEANUP. So something more complex is involved. Nevertheless, unless someone objects in the next day or so, I'd like to commit this change, as I think leaving temp files lying around is a worse problem. -- best regards, Randy