This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: MVFS results


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]