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


Hi Jeremy,

On May 11 14:15, Jeremy Allison wrote:
> On Fri, May 11, 2012 at 07:58:43PM +0200, Corinna Vinschen wrote:
> > On May 11 12:56, starlight.2012q2@binnacle.cx wrote:
> > > /********************************************************************
> > >  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.
> > [...]
> > 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.

That would be nice.  For now, assuming the get_FileIndex has been
introduced with 3.6.0, I'd go with this new implementation, stretched
out and better comments for readability:

inline bool
path_conv::isgood_inode (__ino64_t ino) const
{ 
  /* If the FS doesn't support nonambiguous inode numbers anyway, bail out
     immediately. */
  if (!hasgood_inode ())
    return false;
  /* If the inode numbers are 64 bit numbers or if it's a local FS, they
     are to be trusted. */
  if (ino > UINT32_MAX || !isremote ())
    return true;
  /* The inode numbers returned from a remote NT4 NTFS are ephemeral
     32 bit numbers. */
  if (fs_is_ntfs ())
    return false;
  /* Samba versions since 3.x.x return the real inode numbers, unless the file
     is not on the same device as the root of the share, in which case Samba
     returns a mangled inode number which is a 64 bit number again.  See the
     get_FileIndex function in the Samba sources. */
  if (fs_is_samba () && fs.samba_version () >= 0x03060000)
    return true;
  /* SFU NFS just returns the actual inode number. */
  if (fs_is_nfs ())
    return true;
  /* Otherwise, don't trust the inode numbers. */
  return false;
} 


What do you say?

Thanks,
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]