X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Thu, 12 Mar 2009 23:05:12 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: [1.7] Samba file cp
Message-ID: <20090312220512.GZ9322@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT 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> <Pine DOT CYG DOT 4 DOT 58 DOT 0903121254120 DOT 388 AT PC1163-8460-XP DOT flightsafety DOT com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.CYG.4.58.0903121254120.388@PC1163-8460-XP.flightsafety.com>
User-Agent: Mutt/1.5.19 (2009-02-20)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
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 Mar 12 13:01, Brian Ford wrote:
> On Tue, 10 Mar 2009, Corinna Vinschen wrote:
> > 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?

It seems I introduced this problem with the new advisory file locking
code in 1.7.  I just applied a patch which is supposed to fix your
problem.  Please give it a try.


Thanks for testing,
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/