Mail Archives: cygwin/2009/07/16/13:15:52
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
- Raw text -