X-Spam-Check-By:	sourceware.org
Date:	Thu, 13 Jul 2006 13:21:45 +0200
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
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
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
List-Unsubscribe:	<mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
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/

- Raw text -