Re: APR 1.0 released

Bruce Momjian schrieb:

> Reini Urban wrote:
> 
>>Bruce Momjian schrieb:
>>
>>>OK, care to submit a patch.  As I remember the fix for rename/unlink
>>>also includes how the file is opened with flags.  Anyway, we spent a lot
>>>of time on this so you will have to go back in the archvies to find it
>>>and determine how it can be improved.
>>>
>>>Your track record for Cygwin diagnosis isn't 100%.  I am going to need
>>>complete research before changing anything at this point in beta.
>>
>>Ok, I'll do an analysis and patch which will have a chance to be accepted.
>>Keeping pgrename in CYGWIN is probably a good idea.
>>At least for consistent error reporting (which helped me in finding the 
>>problem)
>>Personally I don't think that any rename()-usleep loop is necessary.
>>I'll check the archives.
> 
> 
> I agree the rename loop seems unnecessary.  I kept it in case we hadn't
> dealt with all the failure places.  Should we remove them now or wait
> for 8.1?  Seems we should keep them in and see if we get reports from
> users of looping forever, and if not we can remove them in 8.1.

we at CYGWIN had similar problems with windows locks on unlink.

if unlink fails with ERROR_SHARING_VIOLATION or ERROR_ACCESS_DENIED, 
unlinking is deferred, put into a delqueue. we do no busy waiting then.
it's done on exit.
The most common problem is the "delete on close" semantics to handle 
removing a file which may be open.

rename only fails on open files. we try first MoveFile, if that fails we 
try MoveFileEx MOVEFILE_REPLACE_EXISTING, but no loop on rename.

http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/syscalls.cc?cvsroot=src
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/delqueue.cc?cvsroot=src

-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/