>>[...] . 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
H. Peter Anvin wrote:
>Are you seriously suggesting changing our behaviour of all the
>conventional filesystems to a non-Unix behaviour, to match cramfs and
>squashfs?
Only one can be right - either with ./.. or without it. And the one[s] who
is/are wrong should be fixed. Take it as a cosmetical issue, though.
Adam J. Richter wrote:
>
> 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.
As a side note, I am only discussing about ./.. for readdir; removing it from
the entire VFS would probably break things like /etc/mail/../../lib/libc.so.6
_in_ the kernel.
> 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.
Sounds "good", because ./.. could always be made the first two entries, and
people could optimize <shrug>. That brings up the point if - despite all sus
specs - we really need . and ...
The explorer.exe in the Neighbor OS also does not show . and ..;
and I doubt any app is using it in FindFile{First,} (open-/readdir),
maybe only for dentry lookup.
>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).
Also a nice idea.
Jan Engelhardt
--
No TOFU for me, please.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
