Mail Archives: cygwin/2009/07/16/12:51:39
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
- Raw text -