This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: CYGWIN inode over Samba share not constructed from IndexNumber


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]