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


Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:

> > 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?
> 

That was me speaking on assumptions rather than checking facts.  I hadn't done 
any strace or procmon on the rm with open file handle, but when I did just that 
right now, I see you are correct that since the filesystem is remote, there was 
no attempt made to involve a recycle bin (just a SetDispositionInformationFile 
with argument Delete:true).

> > 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.

Agreed that this would be nice, but I'm okay with post 1.7.1.

> 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.

I don't mind (my day job makes me use clearcase on a regular basis, but I do 
everything in cygwin by preference.  So making cygwin work nicer with MVFS will 
make me more proficient at work).  But testing cygwin patches can certainly be 
a bit awkward, given that the company firewall blocks ssh and CVS (and I can't 
test at home, given that I have no desire to pay IBM for a personal MVFS 
server ;).  I've had to manually apply your suggested patches against the 1.7.0-
51 source tarball (or the latest snapshot tarball) and/or build at home and 
sneakernet it in to work.  I look forward to the day when ubertree sourceware 
repository transitions to git or similar (at which point I could then use http 
to get at the repository without running into the firewall).

> 
> 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.

OK, give me a while to try and expose something relevant.

-- 
Eric Blake




--
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]