samba - Oct 2000 - Samba inode faking breaks fileutils (and may corrupt the filesystem)

[This is an email copy of a Usenet post to "comp.os.linux"]

When testing a 'rename-files-to-lowercase-names' script, I ran into the
followin problem on an NT share mounted through samba on my RH6.2 Linux
system:

cd /mnt/nt-share mv fOO foo
[no response - killed through Ctrl-C]

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

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.

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.

Versions in use:
RedHat Linux 6.2, with kernel 2.2.16-3
fileutils-4.0-21
samba-2.0.7-4

--
Tim Van Holder - Falcon Software NV
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-Fight spam
- go to http://www.politik-digital.de/spam/

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