lstat reporting different inode numbers on
smfrench at austin.rr.com
Mon Nov 8 01:59:03 GMT 2004
I added support for a new cifs mount option "serverino" which, when the
server supports the CIFS Unix Extensions (such as e.g. Samba server),
will allow the client to use the inode numbers from the server which
should address your issue with lstat showing different inode numbers.
It is now checked into the cifs project bk tree and is available at:
Unless there is strong objection to the name of the mount parm
(serverino vs. the default which is noserverino) this should be ok -
except for the case of Windows servers and Samba servers when the Unix
Extensions are disabled ... the problem is both my Windows box and my
Samba 3.0.8pre server return a 0 as the IndexNumber on FindFirst level
257 (which is among the more common search levels)! Zero
unfortunately is not a particularly unique number to hash on so I
decided to not try to use inode numbers from servers unless the Unix
Extensions are enabled. I think, at least for Samba with the Unix
Extensions disabled, there is a workaround I could try (bumping the
level to 258 or 260) but not sure if I can guarantee that that would
work for Windows (especially for FAT partitions).
So ... how does one get the inode number from Windows servers? How can
you tell if you can trust them in any case?
... there is a FILE_INTERNAL_INFO info level on QPathInfo IFIRC ... does
it work for FAT and CDROMs? In any case it seems fairly expensive to do
QPathInfo for every entry in a search buffer but we could always give
that approach a shot as a second later part of this fix.
As another nit - when the Unix extensions are negotiated we really need
to turn off the roundup logic on the reported allocation size of files
in smbd/trans2.c (although I realize that there are apparent performance
implications to the Windows client if you do it for other client types)
- the Samba lie about file allocation sizes on du is a frequent complaint.
More information about the samba-technical