On Sat, 26 March 2005 02:14:18 +, Phillip Lougher wrote:
>
> Fixing it in Squashfs implies Squashfs is broken. It isn't. If it has
> to be "fixed" in the kenel, fix it in the VFS, it is after all the VFS
> which makes '.' and '..' handling redundant in the filesystem.
There are some islan
On Sat, 26 Mar 2005, Jan Harkes wrote:
> On Fri, Mar 25, 2005 at 02:59:14PM +0100, Jesper Juhl wrote:
> > On Thu, 24 Mar 2005, H. Peter Anvin wrote:
> > > Note that Linux always accepts . and .. so it's just a matter of making
> > > them
> > > appear in readdir.
> > >
> > I'm working on that, bu
>>[...] . 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 pa
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
On Fri, Mar 25, 2005 at 02:59:14PM +0100, Jesper Juhl wrote:
> On Thu, 24 Mar 2005, H. Peter Anvin wrote:
> > Note that Linux always accepts . and .. so it's just a matter of making them
> > appear in readdir.
> >
> I'm working on that, but it's a learning experience for me, so it's going
> a bit
Followup to: <[EMAIL PROTECTED]>
By author:Jan Engelhardt <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> You are right. . and .. do not need to show up (even they have been the
> "leaders" of ls -l ;-), Midnight Commander (`mc`) for example synthesizes
> ".."
> nevertheless.
>
> S
>This situation is easily fixed within
>the application rather than forcing the filesystem to unnecessarily
>fake '.' and '..' entries which are never used.
You are right. . and .. do not need to show up (even they have been the
"leaders" of ls -l ;-), Midnight Commander (`mc`) for example synth
H. Peter Anvin wrote:
Phil Lougher wrote:
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
Phil Lougher wrote:
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 an
On Thu, 24 Mar 2005 15:13:08 -0500, Kyle Moffett <[EMAIL PROTECTED]> 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 i
> Yep, check `-noleaf' in find(1).
No.
At least the copy of find that I just looked at now, in
findutils-4.1.20, makes no such assumption that "." and ".." are the
first two directory entries.
Rather what it does is allow you to suppress an optimization, on file
systems that don't manage their d
Kyle Moffett <[EMAIL PROTECTED]> writes:
> Tommy Reynolds wrote:
> > Then it is broken in several ways.
> >
> > First, file systems are not required to implement ".." (only "." is
> > magical, ".." is a courtesy).
>
> On Mar 24, 2005, at 14:59, H. Peter Anvin wrote:
> > Doesn't have anything to d
On Thu, 24 Mar 2005, H. Peter Anvin wrote:
> Kyle Moffett wrote:
> >
> > IMHO, this is one of those cases where "Be liberal in what you accept
> > and strict in what you emit" applies strongly. New filesystems should
> > probably always emit "." and ".." in that order with sane behavior,
> > and
Jan Engelhardt <[EMAIL PROTECTED]> writes:
>>> > There's probably a number of apps that skip the first two dirents, instead
>>> > of checking for the dot dirs.
>>> Yep, check `-noleaf' in find(1)
>>Then it is broken in several ways.
>>First, file systems are not required to implement ".." (only
Kyle Moffett wrote:
IMHO, this is one of those cases where "Be liberal in what you accept
and strict in what you emit" applies strongly. New filesystems should
probably always emit "." and ".." in that order with sane behavior,
and new programs should probably be able to handle it if they don't. I
Tommy Reynolds wrote:
Then it is broken in several ways.
First, file systems are not required to implement ".." (only "." is
magical, ".." is a courtesy).
On Mar 24, 2005, at 14:59, H. Peter Anvin wrote:
Doesn't have anything to do with sorting order or US-ASCII, it has to
do with readdir order. I
Followup to: <[EMAIL PROTECTED]>
By author:Tommy Reynolds <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> Then it is broken in several ways.
>
> First, file systems are not required to implement ".." (only "." is
> magical, ".." is a courtesy).
>
Sez who? Realistically, most pr
>> > There's probably a number of apps that skip the first two dirents, instead
>> > of checking for the dot dirs.
>> Yep, check `-noleaf' in find(1)
>Then it is broken in several ways.
>First, file systems are not required to implement ".." (only "." is
>magical, ".." is a courtesy).
Heh, wha
Uttered Geert Uytterhoeven <[EMAIL PROTECTED]>, spake thus:
> > There's probably a number of apps that skip the first two dirents, instead
> > of checking for the dot dirs.
>
> Yep, check `-noleaf' in find(1)
Then it is broken in several ways.
First, file systems are not required to implement
On Wed, 23 Mar 2005, Tom Vier wrote:
> On Wed, Mar 23, 2005 at 06:31:24PM +0100, Jan Engelhardt wrote:
> > Which scripts use that? As stated, these two directory entries exist when
> > you
> > stat() them, they just do not show up in readdir(), and I bet few programs
> > care for "." and ".." wh
>> Which scripts use that? As stated, these two directory entries exist when
>> you
>> stat() them, they just do not show up in readdir(), and I bet few programs
>> care for "." and ".." when doing their readdir.
>
>There's probably a number of apps that skip the first two dirents, instead
>of c
On Wed, Mar 23, 2005 at 06:31:24PM +0100, Jan Engelhardt wrote:
> Which scripts use that? As stated, these two directory entries exist when you
> stat() them, they just do not show up in readdir(), and I bet few programs
> care for "." and ".." when doing their readdir.
There's probably a number
>I agree with Jan.
>The . / .. will be useful for some scripts that use it.
Which scripts use that? As stated, these two directory entries exist when you
stat() them, they just do not show up in readdir(), and I bet few programs
care for "." and ".." when doing their readdir.
Jan Engelhardt
-
On Tuesday 22 March 2005 16:59, Jesper Juhl wrote:
> On Tue, 22 Mar 2005, Jan Engelhardt wrote:
> > I have observed that squashfs, when mounted, does not return any "." or
> > ".." pseudo-directories upon readdir.
> > Could this be added? Would there be any objections?
>
> I can't say if there will
On Tue, 22 Mar 2005, Jan Engelhardt wrote:
> Hello,
>
>
> I have observed that squashfs, when mounted, does not return any "." or ".."
> pseudo-directories upon readdir.
> Could this be added? Would there be any objections?
>
I can't say if there will be any objections or not, but if that's
s
Hello,
I have observed that squashfs, when mounted, does not return any "." or ".."
pseudo-directories upon readdir.
Could this be added? Would there be any objections?
Jan Engelhardt
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMA
26 matches
Mail list logo
