Hans Reiser wrote:
David Masover wrote:
That's why we're trying to find something that people won't actually
touch, especially since if we design it right, this will be the last
delimiter introduced at the fs/vfs level.
Uh, no, there needs to be about a dozen or so more.
Where?
From
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hans Reiser wrote:
> Horst von Brand wrote:
>
>
>>Hans Reiser <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>>>Stefan Smietanowski wrote:
>>>
>>>
>>>
I think "..." and ".meta" both serve as a logical delimiter. However
some programs implement
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Neil Brown wrote:
> On Monday July 11, [EMAIL PROTECTED] wrote:
>
>>Stefan Smietanowski wrote:
>>
>>>-BEGIN PGP SIGNED MESSAGE-
>>>Hash: SHA1
>>>
>>>
>>>
Ok, still haven't heard much discussion of metafs vs file-as-directory,
but it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Neil Brown wrote:
On Monday July 11, [EMAIL PROTECTED] wrote:
Stefan Smietanowski wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ok, still haven't heard much discussion of metafs vs file-as-directory,
but it seems like it'd be easier in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hans Reiser wrote:
Horst von Brand wrote:
Hans Reiser [EMAIL PROTECTED] wrote:
Stefan Smietanowski wrote:
I think ... and .meta both serve as a logical delimiter. However
some programs implement their own ... which would make it clash
Hans Reiser wrote:
David Masover wrote:
That's why we're trying to find something that people won't actually
touch, especially since if we design it right, this will be the last
delimiter introduced at the fs/vfs level.
Uh, no, there needs to be about a dozen or so more.
Where?
From
Stefan Smietanowski wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ok, still haven't heard much discussion of metafs vs file-as-directory,
but it seems like it'd be easier in metafs.
Why not implement it inside the directory containg the file ?
Ie the metadata for /home/stesmi/foo
Stefan Smietanowski wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ok, still haven't heard much discussion of metafs vs file-as-directory,
but it seems like it'd be easier in metafs.
Why not implement it inside the directory containg the file ?
Ie the metadata for /home/stesmi/foo
Hubert Chan wrote:
On Wed, 06 Jul 2005 23:42:50 -0700, Hans Reiser <[EMAIL PROTECTED]> said:
Oh no, don't store the whole path, store just the parent list. This
will make fsck more robust in the event that the directory gets
clobbered by hardware error.
I don't think it affects the cost
Hubert Chan wrote:
On Wed, 06 Jul 2005 23:42:50 -0700, Hans Reiser [EMAIL PROTECTED] said:
Oh no, don't store the whole path, store just the parent list. This
will make fsck more robust in the event that the directory gets
clobbered by hardware error.
I don't think it affects the cost of
Markus Törnqvist wrote:
On Fri, Jul 01, 2005 at 05:54:46PM +0200, David Weinehall wrote:
Which would neither need VFS changes nor be dependent on Reiser4 in
any way, so I don't see why this thread lives on. Just get down to
business and implement this metafs =)
I've been gone for a while
Markus Törnqvist wrote:
On Fri, Jul 01, 2005 at 05:54:46PM +0200, David Weinehall wrote:
Which would neither need VFS changes nor be dependent on Reiser4 in
any way, so I don't see why this thread lives on. Just get down to
business and implement this metafs =)
I've been gone for a while
Hubert Chan wrote:
On Wed, 06 Jul 2005 16:33:23 -0400, Horst von Brand <[EMAIL PROTECTED]> said:
Hubert Chan <[EMAIL PROTECTED]> wrote:
If you can store the parents, then finding cycles (relatively)
quickly is pretty easy: before you try to make A the parent of B,
walk up the parent
Jonathan Briggs wrote:
On Wed, 2005-07-06 at 15:51 -0400, Hubert Chan wrote:
On Wed, 06 Jul 2005 12:52:23 -0600, Jonathan Briggs <[EMAIL PROTECTED]> said:
[snip]
It still has the performance and locking problem of having to update
every child file when moving a directory tree to a new
Hans Reiser wrote:
David Masover wrote:
And, once we start talking about applications, /meta will be more
readily supported (as in, some apps will go through a pathname and
stop when they get to a file, and then there's tar). On apps which
don't have direct support for /meta, you'd
Adrian Ulrich wrote:
so all we have left is the issue of whether using /meta costs us
performance, or whether breaking POSIX to add a symlink (such as
foo/...) really gives us that much more usability.
IMHO '/meta' isn't such a good idea, because a chrooted application
won't be able to use
t be made to another file
inside 'contents'.
Hans Reiser wrote:
David Masover wrote:
Now, can anyone think of a situation where we want user-created
hardlinks inside metadata? More importantly, what do we do about it?
I think the equivalent of symlinks would be good enough to get by
Horst von Brand wrote:
Hubert Chan <[EMAIL PROTECTED]> wrote:
On Fri, 01 Jul 2005 03:41:00 -0400, Chet Hosey <[EMAIL PROTECTED]> said:
Horst von Brand wrote:
And who says that a normal user isn't allowed to annotate each and
every file with its purpose or something else?
Explain how
Horst von Brand wrote:
David Masover <[EMAIL PROTECTED]> wrote:
[...]
Just don't allow user-created hardlinks inside either metafs (/meta) or
the magical meta directory inside files.
And what is it useful for, after its advantage was that it was /exactly/
like regular files , a
Hans Reiser wrote:
Hubert Chan wrote:
On Tue, 05 Jul 2005 20:50:08 -0400 EDT, "Alexander G. M. Smith" <[EMAIL
PROTECTED]> said:
That sounds equivalent to no hard links (other than the usual parent
directory one). If there's any directory with two links to it, then
there will be a cycle
Hans Reiser wrote:
Hubert Chan wrote:
On Tue, 05 Jul 2005 20:50:08 -0400 EDT, Alexander G. M. Smith [EMAIL
PROTECTED] said:
That sounds equivalent to no hard links (other than the usual parent
directory one). If there's any directory with two links to it, then
there will be a cycle
Horst von Brand wrote:
David Masover [EMAIL PROTECTED] wrote:
[...]
Just don't allow user-created hardlinks inside either metafs (/meta) or
the magical meta directory inside files.
And what is it useful for, after its advantage was that it was /exactly/
like regular files c, and now
Horst von Brand wrote:
Hubert Chan [EMAIL PROTECTED] wrote:
On Fri, 01 Jul 2005 03:41:00 -0400, Chet Hosey [EMAIL PROTECTED] said:
Horst von Brand wrote:
And who says that a normal user isn't allowed to annotate each and
every file with its purpose or something else?
Explain how you
inside 'contents'.
Hans Reiser wrote:
David Masover wrote:
Now, can anyone think of a situation where we want user-created
hardlinks inside metadata? More importantly, what do we do about it?
I think the equivalent of symlinks would be good enough to get by on for
now for most
Adrian Ulrich wrote:
so all we have left is the issue of whether using /meta costs us
performance, or whether breaking POSIX to add a symlink (such as
foo/...) really gives us that much more usability.
IMHO '/meta' isn't such a good idea, because a chrooted application
won't be able to use
Hans Reiser wrote:
David Masover wrote:
And, once we start talking about applications, /meta will be more
readily supported (as in, some apps will go through a pathname and
stop when they get to a file, and then there's tar). On apps which
don't have direct support for /meta, you'd
Jonathan Briggs wrote:
On Wed, 2005-07-06 at 15:51 -0400, Hubert Chan wrote:
On Wed, 06 Jul 2005 12:52:23 -0600, Jonathan Briggs [EMAIL PROTECTED] said:
[snip]
It still has the performance and locking problem of having to update
every child file when moving a directory tree to a new
Hubert Chan wrote:
On Wed, 06 Jul 2005 16:33:23 -0400, Horst von Brand [EMAIL PROTECTED] said:
Hubert Chan [EMAIL PROTECTED] wrote:
If you can store the parents, then finding cycles (relatively)
quickly is pretty easy: before you try to make A the parent of B,
walk up the parent pointers
Hans Reiser wrote:
> David Masover wrote:
>
>
>>Hans Reiser wrote:
>>
>>
>>
>>>Hubert Chan wrote:
>>>
>>>
>>>
>>>
>>>
>>>>On Fri, 01 Jul 2005 03:06:19 -0500, Dav
Jeremy Maitin-Shepard wrote:
> David Masover <[EMAIL PROTECTED]> writes:
>
> [snip]
>
>
>>>I have. And have seen /no/ benefit to you. Except, of course, the benefit
>>>accrued from some magic in Linus' kernel, by which all format differences
>>&
Horst von Brand wrote:
> David Masover <[EMAIL PROTECTED]> wrote:
>
>>Horst von Brand wrote:
>>
>>>David Masover <[EMAIL PROTECTED]> wrote:
>>>
>>>>David Weinehall wrote:
>>>>
>>>>>On Fri, J
Hans Reiser wrote:
> Hubert Chan wrote:
>
>
>>On Fri, 01 Jul 2005 03:06:19 -0500, David Masover <[EMAIL PROTECTED]> said:
>>
>>
>>
>>
>>>Hubert Chan wrote:
>>>
>>>
>>
>>
>>
>>
>>>>
Hans Reiser wrote:
Hubert Chan wrote:
On Fri, 01 Jul 2005 03:06:19 -0500, David Masover [EMAIL PROTECTED] said:
Hubert Chan wrote:
The main thing blocking file-as-dir is that there are some
locking(IIRC?) issues. And, of course, some people wouldn't want it
to be merged
Horst von Brand wrote:
David Masover [EMAIL PROTECTED] wrote:
Horst von Brand wrote:
David Masover [EMAIL PROTECTED] wrote:
David Weinehall wrote:
On Fri, Jul 01, 2005 at 03:08:58AM -0500, David Masover wrote:
David Weinehall wrote:
[...]
Even if they don't, it would be more
Jeremy Maitin-Shepard wrote:
David Masover [EMAIL PROTECTED] writes:
[snip]
I have. And have seen /no/ benefit to you. Except, of course, the benefit
accrued from some magic in Linus' kernel, by which all format differences
go in a puff of smoke if they are implemented inside
Hans Reiser wrote:
David Masover wrote:
Hans Reiser wrote:
Hubert Chan wrote:
On Fri, 01 Jul 2005 03:06:19 -0500, David Masover [EMAIL PROTECTED] said:
Hubert Chan wrote:
The main thing blocking file-as-dir is that there are some
locking(IIRC
Horst von Brand wrote:
Kevin Bowen <[EMAIL PROTECTED]> wrote:
[...]
So, for instance, if I want to grab all mp3s with Artist "Paul
Oakenfold" and change the genre to "techno" (can you do that?), I can
use Beagle's search tool to find all mp3s by Oakenfold, but to change
the genre, I have
Horst von Brand wrote:
David Masover <[EMAIL PROTECTED]> wrote:
David Weinehall wrote:
On Fri, Jul 01, 2005 at 03:08:58AM -0500, David Masover wrote:
David Weinehall wrote:
GNOME and KDE run on operating systems that run other kernels than
Linux, hence they have to implement the
Horst von Brand wrote:
David Masover [EMAIL PROTECTED] wrote:
David Weinehall wrote:
On Fri, Jul 01, 2005 at 03:08:58AM -0500, David Masover wrote:
David Weinehall wrote:
GNOME and KDE run on operating systems that run other kernels than
Linux, hence they have to implement their own
Horst von Brand wrote:
Kevin Bowen [EMAIL PROTECTED] wrote:
[...]
So, for instance, if I want to grab all mp3s with Artist Paul
Oakenfold and change the genre to techno (can you do that?), I can
use Beagle's search tool to find all mp3s by Oakenfold, but to change
the genre, I have to use
40 matches
Mail list logo
