[linux-cifs-client] Re: lstat reporting different inode numbers on

[Steve French]

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:

    
http://cifs.bkbits.net:8080/linux-2.5cifs/gnupatch@418ece9b_dRQfjBCq_lZlc1z1Crlqw

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.