Re: "replaced while being copied" - was ... RE: Solved partially by findutils 4.3 - RE: "inode changed", ...

[Ty Sarna <tsarna at sarna dot org>]

Corinna Vinschen wrote:
> No, I think that's enough for now.  As suggested by somebody on this
> list some weeks ago, I will change the condition on which I use the real
> inode number instead of faking the inode number using a hash value
> depending on the FILE_SUPPORTS_OBJECT_IDS flag, except for Samba file
> systems.  This should lower the chance to get unreliable inode numbers.

I'm running a cygwin install from yesterday (lib 1.5.20) and running
into this issue.  The remote filesyste is a Samba share (2.2.8a), part
of which is local to that box and other parts of which are in turn NFS
mounted from NetApps and various other things.  I don't have much/any
control of this environment... 

Even if I could get the Samba upgraded to a newer one that reported the
correct file IDs, I don't know that it would help since sometimes it
would be reporting the information from NetApp, which I understand can
also be wrong? Further even if Cygwin has logic to deal with the NetApp
it won't help in this case because it won't realize that's what it's
ultimately talking to...

Perhaps the best thing to do is add a registry key/env var/some other
kind of override that users can set, to prevent cygwin from trying to be
intelligent here and just use the old hashing method always for Samba
(which worked fine for me in this exact setup with older Cygwin)

It's nice when software can guess what the right thing is, but it's always
good to have an override knob in case the guess is wrong :-)

Thanks

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/