Re: Problem with stat() on CIFS.
Suresh Jayaraman <[email protected]>
| Newsgroups | gmane.linux.file-systems.cifs |
|---|---|
| Message-ID | <[email protected]> |
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