Re: Problem with stat() on CIFS.

On 12/18/2009 05:09 PM, Jeff Layton wrote:
> On Fri, 18 Dec 2009 12:31:18 +0530
> Suresh Jayaraman <[email protected]> wrote:

>>>>
>>>> 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.
>>>>
>>>
>>> It doesn't get the uniqueid wrong here, it's just that the uniqueid is a
>>> different value from the inode number. With samba, the "UniqueID" is a
>>> fusion of the device ID and inode number. That value is supposed to be
>>> unique over the scope of the entire server whereas inode numbers are
>>> only unique over the scope of a single filesystem.
>>>
>>> When mounting with POSIX extensions we use the actual inode number
>>> provided by the POSIX calls as an inode number. When mounting without
>>> them, we don't have a way to get that so we use the uniqueid.
>>>
>>> UniqueID's are very often greater than 2^32 however, so that value
>>> often happens to run afoul of glibc's trickery here. The real fix is to
>>> make sure that you compile your programs with LFS support
>>> (i.e. with -D_FILE_OFFSET_BITS=64).
>>
>> Jeff, thanks for the great explanation. However, I find no documentation
>> (atleast user/administrator level) about this in mount.cifs man page
>> (and no mention about nounix mount option as well). Would it help to add
>> this piece of information to mount.cifs man page as the change (UniqueId
>> instead of inode numbers) is visible to users. If yes, I can send a
>> documentation patch.
>>
> 
> That would be great...
> 
> At some point, it would also be good (and more consistent for users) to
> split up the manpage. Make a cifs(5) manpage (similar to the nfs(5)
> manpage) that has most of the info in the current mount.cifs manpage,

+1

> and make the mount.cifs manpage *just* for the mount.cifs program
> itself (analogous to the mount.nfs manpage).
> 

Yes, it's getting longer.


Thanks,

-- 
Suresh Jayaraman