From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3552 invoked by alias); 11 May 2012 17:59:42 -0000 Received: (qmail 3083 invoked by uid 22791); 11 May 2012 17:59:00 -0000 X-Spam-Check-By: sourceware.org Received: from aquarius.hirmke.de (HELO calimero.vinschen.de) (217.91.18.234) by sourceware.org (qpsmtpd/0.83/v0.83-20-g38e4449) with ESMTP; Fri, 11 May 2012 17:58:46 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id E85FF2C14F1; Fri, 11 May 2012 19:58:43 +0200 (CEST) Date: Fri, 11 May 2012 17:59:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Cc: starlight.2012q2@binnacle.cx, jra@samba.org Subject: Re: CYGWIN inode over Samba share not constructed from IndexNumber Message-ID: <20120511175843.GL13090@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com, starlight.2012q2@binnacle.cx, jra@samba.org References: <6.2.5.6.2.20120511125624.05cd1ff8@binnacle.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20120511125624.05cd1ff8@binnacle.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com X-SW-Source: 2012-05/txt/msg00243.txt.bz2 On May 11 12:56, starlight.2012q2@binnacle.cx wrote: > Here is the logic Samba uses for inode > determination, per Jermey Allison: > > > > Ok, here's how we construct the 64-bit return > value for that field: > > /******************************************************************** > Create a 64 bit FileIndex. If the file is on the same device as > the root of the share, just return the 64-bit inode. If it isn't, > mangle as we used to do. > ********************************************************************/ > > uint64_t get_FileIndex(connection_struct *conn, const SMB_STRUCT_STAT *psbuf) > { > uint64_t file_index; > if (conn->base_share_dev == psbuf->st_ex_dev) { > return (uint64_t)psbuf->st_ex_ino; > } > file_index = ((psbuf->st_ex_ino) & UINT32_MAX); /* FileIndexLow */ > file_index |= ((uint64_t)((psbuf->st_ex_dev) & UINT32_MAX)) << 32; /* FileIndexHigh */ > return file_index; > } Which Samba version introduced this behaviour? Originally, way back when Samba 3.0.28 was new, the inode numbers were always mangled to be 64 bit numbers, AFAIK. The code in Cygwin which doesn't trust 32 bit inode numbers on remote drives is there for ages, at least since 2007. Fortunately we have an interface which allows to fetch the Samba version number from the server since Samba 3.0.28a. So, if we know which Samba version started to return the real 32 bit inode number, we can adapt. Btw., https://lists.samba.org/archive/samba/2012-May/167383.html is a bit of a disappointment. There's nothing "oddball" in the decision not to trust remote inode numbers <= 0xffffffff. It all started with the fact that remote NT4 servers returned ephemeral file IDs <= 0xfffffff. And there was some problem with 2.x Samba shares as well, which also returned weird file IDs, but I don't recall the details. This is old code, I grant you that, but we had our reason to do so at the time. Here's the code in question including comment: inline bool path_conv::isgood_inode (__ino64_t ino) const { /* We can't trust remote inode numbers of only 32 bit. That means, remote NT4 NTFS, as well as shares of Samba version < 3.0. The known exception are SFU NFS shares, which return the valid 32 bit inode number from the remote file system unchanged. */ return hasgood_inode () && (ino > UINT32_MAX || !isremote () || fs_is_nfs ()); } Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple