Re: inode numbers differ when accessing the same folder with a differently-cased path

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



You might check if the server is reporting "UniqueIds" correctly in the protocol
(we get the inode number by default from what the server returns, but
turn off that feature and autogenerate them if the server returns illegal
inode numbers such as '0').  We log a warning to dmesg if using the
server reported inode number is disabled.

Which dialect is this  SMB3 (default vers=3.0) or CIFS (vers=1.0)?
What is the server file system type under Samba (ext4? btrfs? xfs?)

Also would be useful to know if you considered turning on case sensitivity
in smb.conf (on the server for the share, if using SMB2.1 or later)?

If you are using the default dialect for more recent kernels
this seems more plausible (the problem you report) but extremely
unlikely with cifs (vers=1.0) especially due to the CIFS Unix Extensions
since if you searched for the file with different case you would have
gotten a file not found for the other one (and samba should always
report inode numbers correctly).


On Sun, Aug 19, 2018 at 11:10 AM Simon <git@xxxxxxxx> wrote:
>
> I'm using a library that detects if two paths are the same file by
> comparing the dev and ino numbers of the files. When using the library
> on a mounted samba share (with cifs), the inode numbers differ when the
> path's case is different. I'd like to know if there's a way to get
> around this issue and detect that they are in fact the same file.
>
> For instance, "GoodFellas (1990)" gives me {dev: 46, ino: 10248}
> and "Goodfellas (1990)" gives me {dev: 46, ino: 11984}
>
> Upstream bug: https://github.com/BurntSushi/same-file/issues/41



-- 
Thanks,

Steve



[Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux