[linux-cifs-client] Problem with stat() on CIFS.

[Suresh Jayaraman]

On 12/17/2009 09:05 AM, Bart Oldeman wrote:
> Hi,
> 
> on 32-bit systems using plain stat() (not stat64()) is problematic on
> CIFS mount points (kernel 2.6.32):
> 
> $ stat /home/bart/cifs
>   File: `/home/bart/cifs'
>   Size: 0               Blocks: 0          IO Block: 16384  directory
> Device: 11h/17d Inode: 8839049314305  Links: 1
> Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
> Access: 2009-12-16 22:14:55.000000000 -0500
> Modify: 2009-12-16 22:14:00.000000000 -0500
> Change: 2009-12-16 22:14:00.000000000 -0500
> 
> As you can see the inode number is very high: 0x80a00650001
> Glibc's stat() calls the kernel's stat64(), tries to convert the
> struct stat64 structure to a "struct stat" and fail.
> 
> Note that I've only seen this with a Samba server when Unix extensions
> were NOT enabled -- if they are enabled I get 0x650001 as the inode
> number which is OK.

I managed to reproduce this, but it is not clear to me what is the
expected behavior esp. with various combination of nounix and serverino
mount options.

I think this is what is happening:

With "nounix" mount option or unix extentions disabled (and serverino
option being default) against Samba server, cifs client tries to send a
QUERY_PATH_INFO with ALL_INFO interest level (which doesn't seem to have
a place holder for unique inode number). It then tries to send a
QUERY_FILE_INFO request with FILE_INTERNAL_INFO interest level to get
the Server inode number and it gets the unique Id (IndexNumber) wrong
here. Whereas when unix extension is enabled, the client gets the unique
inode number as part of the response to QUERY_PATH_INFO with
FILE_UNIX_BASIC level of interest.

Is the client expected to get the server inode number from the server if
Unix extensions is disabled? If yes, it appears to me that the Samba
server (3.2.4 in my case) when unix extension is disabled is not sending
the Server inode number correctly. Or perhaps QUERY_FILE_INFO with
FILE_INTERNAL_INFO level of interest is not the right way to get the
server inode number (I couldn't find any documentation on this).
I think this issue had been there for long has been exposed now by
making serverino as default.

Is your server guaranteed to return unique inode numbers? If not as a
workaround, try mounting with "noserverino" mount option and see whether
the problem goes away.


Thanks,


-- 
Suresh Jayaraman