On Jul 16 16:25, Eric Blake wrote: > Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes: > > > > > For instance, maybe it chokes on the sharing flags. I'd try with > > > > FILE_SHARE_VALID_FLAGS instead of just FILE_SHARE_DELETE. > > Nope, still chokes on FILE_SHARE_VALID_FLAGS with access denied.
Too bad. But actually I expected that. > > Another idea would be that the MVFS driver refuses the open request for > > DELETE *because* the R/O flag is set. That's wrong behaviour but it is > > as it is. If I'm right, you would have to open the file with > > FILE_WRITE_ATTRIBUTES permission only, remove the R/O flag, re-open the > > file with DELETE access, close the original handle, and then go ahead > > with the default unlink procedure, along these lines (tested on FAT): > > > > Definite improvement. I'm now able to delete read-only files on MVFS > when they are not held open by any process. That's Windows default behaviour anyway. You had the same in Cygwin 1.5 so it's not a regression. > I don't know if this > rearrangement has any speed penalties for other filesystems that don't > have this problem, or if you might want to make the path taken > conditional on the file system type. The code is generic enough to work for all filesystems and I don't think it's much of a penalty. That's why I explicitely reopen the file using the given handle rather than to open the file again by name after removing the R/O attribute. I'm going to apply it as is. Thanks for testing. Besides, I still hope that the R/O DOS attribute will mostly not be in the way in future, given that Cygwin will not set it anymore if the filesystem, supports ACLs... > There are still issues trying to delete open files, where readdir() > and stat() still see the file after it has been deleted, but utimes() > and open() fail because it has been marked for deletion. Do you need > an strace() of the rm and what it attempted with the recycle bin? At Erm... it tries to use the recycle bin? Why? AFAICS, MVFS has the FILE_REMOTE_DEVICE device characteristic set, so it's logically always a remote drive and unlink_nt does not try to move the file to the recycle bin if it's a remote drive. Can you please check again? > any rate, as soon as the last handle is closed, then the readdir() and > stat() no longer see the file. Maybe for MVFS it would be better to > return EBUSY instead of letting unlink succeed when the handle is > still open by another process: That would be something I could add, but this isn't overly important right now, IMHO. Just bug me with this again at one point. I assume this can be a generic solution as well for any remote filesystem. > What do you want me to help tackle next? I'm going to check in the changes to unlink_nt for now and add a MVFS filesystem check. Then I'll always create winsymlinks when the target filesystem is MVFS. That should deal with the original symlink problem reported in the other thread. Of course, I need you to test this, if you don't mind. Next is the cp -p vs. touch problem. Can you try to find out what's the difference? If strace doesn't help alone, procmon should show the difference quite nicely. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
