Re: Squashfs without ./..

[Phil Lougher <phil.lougher@gmail.com>]

On Thu, 24 Mar 2005 15:13:08 -0500, Kyle Moffett <mrmacman_g4@mac.com> wrote:
> I would add ".." and "." to squashfs, just so that it acts like the rest
> of the filesystems on the planet,

Cramfs also doesn't store '.' and '..', which is where I got the idea
from in the first place when originally implementing Squashfs.

Filesystems don't need to store '.' or ''..' in the filesystem, as
they're never looked up by the VFS - as mentioned elsewhere in this
thread, the VFS handles '.' and '..' internally.

Not storing the redundant '.' and '..' entries within the filesystem
achieves a small but nonetheless useful space saving.

> even if it has to emulate them
> internally.

Making readdir return '.' and '..' is trivially easy, as all the
required information to fake '.' and '..' entries are present.

The lack of '.' and '..' entries hasn't caused any problems despite
cramfs/squashfs being used for a large number of years.  I'm inclined
to believe any application that _relies_ on seeing '.' and '..'
returned by readdir is broken.  This situation is easily fixed within
the application rather than forcing the filesystem to unnecessarily
fake '.' and '..' entries which are never used.

> OTOH, I think that the default behavior of find is broken
> and should probably be fixed, maybe by making the default use the full
> readdir and optionally allowing a -fast option that optimizes the
> search using such tricks.
> 

Cramfs/Squashfs and other filesystems set the link count on files and
directories to 1, find correctly interprets this to mean it can't do
any of its 'tricks' and doesn't use any optimisations.

Phillip
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/