https://bugzilla.kernel.org/show_bug.cgi?id=196405 --- Comment #3 from Theodore Tso (tytso@xxxxxxx) --- > Is it necessary for it to "break" (quotes because 1 seems to be a kind-of > wildcard) at such a low and weird value? The reason for choosing 1 is because there were other file systems where they don't have a '..' where the link count of the directory is 1. In fact, I just checked; I can't find anything in POSIX or the Single Unix Specification which guarantees that '.' and '..' are hard links. It is that way historically, but there are file systems such as VFAT where this is not true. That's important because there are programs which, if they see a link count of 42, if they are doing a directory tree walk, and they see 42 directories, they will assume that there are no more subdirectories at that level. I suppose we could have used a link count of 0xFFFFFFFF as the magic "lots" value, but that could potentially trigger overflow bugs in programs. And given that most of these programs already understand that 1 is "lots" so they can do the right thing when you run "find" on a mounted thumb drive using VFAT. > This behavior doesn't occur with ext4 ram disks. Run the same command, > possibly > with an even higher number, but within an ext4 ram disk, created via > > $ sudo mount -t ramfs -o size=4G ext4 <path> That's not a ext4 ram disk. That's a tmpfs partition (ramfs is an alias for tmpfs). "ext4" in the above invocation can be anything, and it has no meaning. Just as "mount -t proc proc /proc" is equivalent to "mount -t proc xyzzy /proc", the above can also be: sudo mount -t ramfs -o size=4G xyzzy <path> And it will be the same as "sudo mount -t ramfs -o size=4G ext4 <path>". - Ted -- You are receiving this mail because: You are watching the assignee of the bug.
