Samba inode faking breaks fileutils (and may corrupt the filesystem)

Urban Widmark urban at svenskatest.se
Wed Oct 18 19:31:47 GMT 2000


On Tue, 17 Oct 2000, Tim Van Holder wrote:

> as a result, I ended up with a structure like this:
> /mnt/nt-share/fOO/fOO/fOO/fOO/fOO/fOO/fOO/fOO/fOO/fOO/...

Easily reproducable on the latest version. I'll look into this soon,
unless someone else fixes it before me (hint, hint :)

> It seems mv happily moves the directory into itself. This directory tree
> is nested so deeply even that NT is unable to access or even delete it, so
> it effectively becomes immortal.

On the NT box or when doing it over smbfs? If not from smbfs it is
probably "immortal" only to the application you were using to delete it
(explorer?).

> The problem seems to be with samba's inode number faking, as it generates
> a new fake inode if a directory entry is referred to by a different name
> (eg a directory entry foo will have gotten inode number 1234, but if it's
> accessed as FOO, it gets a new inode generated for it). This breaks
> fileutils, as they use the inode number to detect identical files.

Samba does not fake inode numbers, smbfs does. And the behaviour is
related to dcache/dentries too, not only inodes. It is possible to create
a directory and get the move to fail with the expected error message.

Btw, be careful when doing operations over smbfs to a deep directory
structure. Before 2.2.18-pre15 there was no checks that the pathlengths
remain within the fixed buffersizes of smbfs (of smb/cifs ?). You can
easily crash your linux machine by doing that.

/Urban





More information about the samba mailing list