On Jul 12 14:39, Ty Sarna wrote: > 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 :-)
Sorry, but I still think it's possible to get it right in Cygwin w/o such a knob. What about helping to debug why that happens instead and get a knob-free solution? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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/
