This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: CYGWIN inode over Samba share not constructed from IndexNumber
On Fri, May 11, 2012 at 07:58:43PM +0200, Corinna Vinschen wrote:
> 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 ());
> }
The get_FileIndex() code has been there since at least 3.6.x, but
I'll try and track down when it was first introduced.
Jeremy.
--
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