Re: Squashfs without ./..

From: Adam J. Richter (adam_at_yggdrasil.com)
Date: 03/27/05

  • Next message: Jan Engelhardt: "Re: INITRAMFS: junk in compressed archive" 
    Date:	Sun, 27 Mar 2005 16:11:59 +0800
To: jengelh@linux01.gwdg.de

    Jan Engelhardt wrote:
    >[...] . and .. do not need to show up (even they have been the
    >"leaders" of ls -l ;-), Midnight Commander (`mc`) for example synthesizes ".."
    >nevertheless.
    >
    >So - what about removing . and .. in readdir for all "standard harddisk
    >filesystems" (ext*,reiser*, [jx]fs)? I mean, one party always has to loose...~v

            Eliminating the "." and ".." emulation in many individual
    file systems would probably eliminate a moderate amount of code
    from libfs/fs.c, a number of other virtual file systems and probably
    every physical file system that does not actually store "." and "..".
    It is very appealing to me.

            Unfortunately, the description of readdir() in the Single Unix
    Specification version 3 says:

    | [...] If entries for dot or dot-dot exist, one entry shall be returned
    | for dot and one entry shall be returned for dot-dot; otherwise, they
    | shall not be returned.

            Unless attempts to access "." and ".." would really return -ENOENT,
    then at least the C library's readdir() function has to return them.
    At least that's how I read it.

            Although I do not believe that absolute compliance to SUSPv3
    is a requirement demanded by those who make the "official" kernel
    releases, I think that complying closely to SUSPv3 and many other
    standards is considered to be worth a lot (in terms of technical
    trade-offs) so that software that complies to these standards
    is more likely to run properly on systems running the Linux kernel.
    So, I would expect that patches changing squashfs and other file systems
    whose readdir functions currently fail to return "." and ".." would
    be likely to be integrated (if they meet all the other usual quality
    standards), at least for now.

            That said, I can think of at least two approaches by which
    we could eliminate the "." and ".." emulation littering most Linux
    file system drivers.

            The first way would be to change the kernel so that the
    underlying readdir system call does not return "." or "..", but
    have the C library do the emulation. The C library can maintain
    the state information for this purpose easily because opendir()
    returns a pointer to an opaque structure that the C library
    allocates.

            Alternatively, we could preserve the opendir system call's
    behavior, but pick apart a few of the routines in fs/libfs.c to come
    up with some more general utiity routines to implement the common case
    where the first readdir returns ".", the second returns "..", a seek
    pointer of 0 means before the ".", a seek pointer of 1 means before
    the "..", and a seek pointer of 1 means immediately after the "..".
    The actual implementation would be pretty short, but having an
    interface that the client file systems could easily accomodate might
    take some care (for example, accomodating their locking schemes while
    keeping the interface simple enough so that the client file system
    drivers are still made smaller by using it).

                        __ ______________
    Adam J. Richter \ /
    adam@yggdrasil.com | g g d r a s i l
    -
    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/

  • Next message: Jan Engelhardt: "Re: INITRAMFS: junk in compressed archive"

    Relevant Pages