X-Spam-Check-By: sourceware.org Date: Thu, 13 Jul 2006 13:21:45 +0200 From: Corinna Vinschen To: cygwin AT cygwin DOT com Subject: Re: "replaced while being copied" - was ... RE: Solved partially by findutils 4.3 - RE: "inode changed", ... Message-ID: <20060713112145.GC17383@calimero.vinschen.de> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <20060124121025 DOT GG8318 AT calimero DOT vinschen DOT de> <20060712183940 DOT 04DA47C166A AT kohaku DOT sarna DOT org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060712183940.04DA47C166A@kohaku.sarna.org> User-Agent: Mutt/1.4.2i Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com 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/