X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=-0.9 required=5.0 tests=AWL,BAYES_40
X-Spam-Check-By:	sourceware.org
Date:	Thu, 12 Mar 2009 13:01:39 -0500
From:	Brian Ford <Brian DOT Ford AT FlightSafety DOT com>
Reply-To:	cygwin AT cygwin DOT com
To:	cygwin AT cygwin DOT com
Subject:	Re: [1.7] Samba file cp
In-Reply-To:	<20090310214918.GG9322@calimero.vinschen.de>
Message-ID:	<Pine.CYG.4.58.0903121254120.388@PC1163-8460-XP.flightsafety.com>
References:	<Pine DOT CYG DOT 4 DOT 58 DOT 0903101115100 DOT 3000 AT PC1163-8460-XP DOT flightsafety DOT com> <49B69EBB DOT 4020405 AT gmail DOT com> <Pine DOT CYG DOT 4 DOT 58 DOT 0903101233150 DOT 3000 AT PC1163-8460-XP DOT flightsafety DOT com> <20090310214918 DOT GG9322 AT calimero DOT vinschen DOT de>
MIME-Version:	1.0
X-IsSubscribed:	yes
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
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 Tue, 10 Mar 2009, Corinna Vinschen wrote:

> And given the high values they seem to be faked inode numbers.  But that
> doesn't match the below GetVolInfo output.  This flag combination should
> result in identical operation on 1.7 and 1.5.25.

Obviously, it doesn't ;-).

> I just tested this against a samba 3.2.6 server and I can't reproduce your
> problem.  I'm wondering if that's something about the age of the Samba
> server in your case.  Old 2.x Sambas did exactly what you're seeing
> above.  The inode numbers are arbitrary values between each call fetching
> file information from the server.  See the comment in fhandler_disk_file.cc,
> in function path_conv::isgood_inode().

    return hasgood_inode () && (ino > UINT32_MAX || !isremote () ||
fs_is_nfs ());

	1 && (0 || !1 || 0) = false

> As I said, it works fine for me.  It would be helpful if you could debug
> this situation.  The important places are
>
>   fhandler_base::fstat_helper() in fhandler_disk_file.cc for
>   ls(1)/stat(1)/stat(2)

fhandler_disk_file.cc (fstat_helper): 531
  /* Enforce namehash as inode number on untrusted file systems. */
  if (pc.isgood_inode (nFileIndex))
    buf->st_ino = (__ino64_t) nFileIndex;
  else
    buf->st_ino = get_ino ();

So pc.isgood_inode returns false because ino is < UINT_32MAX and the other
exceptions are false, but we call get_ino wich does:

  __ino64_t get_ino () { return ino ?: ino = hash_path_name (0,
pc.get_nt_native_path ()); }

and returns the non-zero ino instead of calling hash_path name?  I thought
we just said ino < UINT_32MAX was bad?

-- 
Brian Ford
Staff Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained crew...

--
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 -