On Wed, Apr 20, 2005 at 18:21:44 +0200, Tomas Telensky wrote:
> > Let me rephrase my question a little bit: BESIDES the obvious usage of
> > "." entry, in terms of the filesystem, what is the purpose of "." entry?
> >
> > The obvious answer is that you can refer to the current directory using
> > "./", however, in order to look up the "." entry, the kernel must have a
> > knowledge of the current directory in the first place, doesn't it? The
> > kernel needs the directory table for the current directory to look up
> > which inode the "." entry refers to. Doesn't that seem a little
> > redundant, since the kernel already knows what the current directory is?
> > If the kernel is already caching the current directory table, it might
> > as well just cache the current directory's inode.
>
> I think you touched the point. There MIGHT be a situation in which you don't
> have the inode of the current directory, just the table, and you want to
> access the inode.
Actually some filesystems store it on disk (ext2/3, reiserfs) and
other's don't (fat, jfs). Those that don't store it don't store '..'
either. And they don't need to -- the invariants of dcache guarantee
that this information is always in memory (dentry holds reference to the
inode, so we have '.' and to it's parent, so we have '..').
(Well, actually if NFS server can load things by inode number and then
parent does not have to be there -- for filesystems that support NFS.)
For userland there are two reasons however:
1) You can open './something' as 'something', but you can't open '.' as
''. So for this corner case it is necessary.
2) If you need to construct paths, than it allows you to simply do
path + '/' + name
while otherwise you'd have to do
path ? path + '/' + name : name
which is a PITA in expansion-based languages like make or shell.
By the way, it's the same reason for which foo//bar is equivalent to
foo/bar -- so you don't need to care whether there is / at the end of
the path component.
-------------------------------------------------------------------------------
Jan 'Bulb' Hudec <bulb@xxxxxx>
Attachment:
signature.asc
Description: Digital signature
