Messages in this thread | | | Date | Sun, 27 Jun 1999 13:14:17 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: generalizing . and .. |
| |
On Sun, 27 Jun 1999, Rick Hohensee wrote:
> 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/
| |