> Intuition tells you that /usr is not 1k. Or it did before you became
> immersed in unix. The "size of a directory" is not the size of the
> "file" containing the names of the files and subdirs in a directory.
> It's the du of the directory. That's the size. The greenest newbie
> makes more sense in this regard than the "illuminati" often do.
Directory doesn't *contain* files. It refers to them. If you don't
understand that - you don't understand the basics of UNIX filesystems.
That's where the confusion comes from.
> It's quite non-trivial to implement however, at some definite performance
> hit. Not as much as doing a real du every time you access a file, but some
> hit. That, of course, is why it's not like that now. I'm not yet up to
> implementing such a beast, but I did fool around with pretending such a
> thing existed. I wrote a script to du everything and put the output of du
> in ... in every directory. The one thing about just that lame emulation
> that I noticed really wanted lower level support was that a dir with ...
> in it is not considered empty.
And it isn't. It contains the reference to object that can become garbage
when you remove this directory.
> So maybe there's a simple modification to the status quo to support
> playing around with such things. The status quo is not far from
> "A dir containing files with names consisting only of periods is
> considered empty."
Yes it is. Names are not an issue. It's a filesystem, not a filemanager.
Directory is empty if it contains nothing except references to itself and
its parent.
> I suggest ... be reserved for the du-equivalent of the dir, if such a
> thing were to occur.
Please, learn how the thing works, OK?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/