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
David Masover <[EMAIL PROTECTED]> wrote:
> Hans Reiser wrote:
> > Horst von Brand wrote:
> >>Hans Reiser <[EMAIL PROTECTED]> wrote:
> >>>Stefan Smietanowski wrote:
[...]
> > Better to spend one's mind looking for bugs instead of this issue.
>
> .if bugs were seen as such a big deal.
>
Neil Brown wrote:
>On Tuesday July 12, [EMAIL PROTECTED] wrote:
>
>
>>Neil Brown wrote:
>>
>>
>>
>>>Maybe it is worth repeating Al Viro's suggestion at this point. I
>>>don't have a reference but the idea was basically that if you open
>>>"/foo" and get filedescriptor N, then
>>>
On Tuesday July 12, [EMAIL PROTECTED] wrote:
> Neil Brown wrote:
>
> >
> >
> >Maybe it is worth repeating Al Viro's suggestion at this point. I
> >don't have a reference but the idea was basically that if you open
> >"/foo" and get filedescriptor N, then
> > /proc/self/fds/N-meta
> >is a
On Tuesday July 12, [EMAIL PROTECTED] wrote:
> >
> > Maybe it is worth repeating Al Viro's suggestion at this point. I
> > don't have a reference but the idea was basically that if you open
> > "/foo" and get filedescriptor N, then
> >/proc/self/fds/N-meta
>
> How am I supposed to get there
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.
But not this year.
-
To
-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
Neil Brown wrote:
>
>
>Maybe it is worth repeating Al Viro's suggestion at this point. I
>don't have a reference but the idea was basically that if you open
>"/foo" and get filedescriptor N, then
> /proc/self/fds/N-meta
>is a directory which contains all the meta stuff for "/foo".
>Then it is
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 metafs.
> >
> >
> > Why not implement 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
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.
But not this year.
-
To unsubscribe
On Tuesday July 12, [EMAIL PROTECTED] wrote:
Maybe it is worth repeating Al Viro's suggestion at this point. I
don't have a reference but the idea was basically that if you open
/foo and get filedescriptor N, then
/proc/self/fds/N-meta
How am I supposed to get there with a shell
On Tuesday July 12, [EMAIL PROTECTED] wrote:
Neil Brown wrote:
Maybe it is worth repeating Al Viro's suggestion at this point. I
don't have a reference but the idea was basically that if you open
/foo and get filedescriptor N, then
/proc/self/fds/N-meta
is a directory which
Neil Brown wrote:
On Tuesday July 12, [EMAIL PROTECTED] wrote:
Neil Brown wrote:
Maybe it is worth repeating Al Viro's suggestion at this point. I
don't have a reference but the idea was basically that if you open
/foo and get filedescriptor N, then
/proc/self/fds/N-meta
is a
David Masover [EMAIL PROTECTED] wrote:
Hans Reiser wrote:
Horst von Brand wrote:
Hans Reiser [EMAIL PROTECTED] wrote:
Stefan Smietanowski wrote:
[...]
Better to spend one's mind looking for bugs instead of this issue.
.if bugs were seen as such a big deal.
I think it's far
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
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 metafs.
Why not implement it inside the directory
Neil Brown wrote:
Maybe it is worth repeating Al Viro's suggestion at this point. I
don't have a reference but the idea was basically that if you open
/foo and get filedescriptor N, then
/proc/self/fds/N-meta
is a directory which contains all the meta stuff for /foo.
Then it is trivial to
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 with
>>>them. Naturally if some program created
On Mon, Jul 11, 2005 at 10:33:24PM -0400, Horst von Brand wrote:
> Hans Reiser <[EMAIL PROTECTED]> wrote:
> > I chose '' (four dots) because it clashes with less, not three dots.
>
> Is this some kind of "My dots are more than yours" contest?!
>
> /None/ of them is safe. ".meta", "...",
David Masover <[EMAIL PROTECTED]> wrote:
[...]
> Both camps seem to want to allow easy access to the metadata of a
> file, whether we're given that file as an inode or as a pathname.
> That's why I suggested /meta/vfs and /meta/inode -- sometimes I want
> to look up a file by name, and sometimes
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 with
> > them. Naturally if some program created a directory called .meta we're
> >
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
On Sun, 10 Jul 2005 02:00:49 +0200, Stefan Smietanowski <[EMAIL PROTECTED]>
said:
> So basically if I write a program that works in both Gnome and KDE I
> should (according to your description) implement my own VFS that will
> use the Gnome or KDE VFS that will then use the OS VFS.
Either that,
Stefan Smietanowski wrote:
>
> I think "..." and ".meta" both serve as a logical delimiter. However
> some programs implement their own "..." which would make it clash with
> them. Naturally if some program created a directory called .meta we're
> equally screwed.
I chose '' (four dots)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi.
>> Why not implement it inside the directory containg the file ?
>>
>> Ie the metadata for /home/stesmi/foo is in /home/stesmi/.meta/foo
>>
>> This should be suit both camps I'd think?
>
> You still need to figure out the parent of "foo", which
> So basically if I write a program that works in both Gnome and KDE
> I should (according to your description) implement my own VFS that
> will use the Gnome or KDE VFS that will then use the OS VFS.
>
> Is it only me finding that a little silly?
Maybe. Advantages of kde/gnome/other userland
So basically if I write a program that works in both Gnome and KDE
I should (according to your description) implement my own VFS that
will use the Gnome or KDE VFS that will then use the OS VFS.
Is it only me finding that a little silly?
Maybe. Advantages of kde/gnome/other userland vfs ?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi.
Why not implement it inside the directory containg the file ?
Ie the metadata for /home/stesmi/foo is in /home/stesmi/.meta/foo
This should be suit both camps I'd think?
You still need to figure out the parent of foo, which isn't
Stefan Smietanowski wrote:
I think ... and .meta both serve as a logical delimiter. However
some programs implement their own ... which would make it clash with
them. Naturally if some program created a directory called .meta we're
equally screwed.
I chose '' (four dots) because it
On Sun, 10 Jul 2005 02:00:49 +0200, Stefan Smietanowski [EMAIL PROTECTED]
said:
So basically if I write a program that works in both Gnome and KDE I
should (according to your description) implement my own VFS that will
use the Gnome or KDE VFS that will then use the OS VFS.
Either that, or
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
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 with
them. Naturally if some program created a directory called .meta we're
equally screwed.
I
David Masover [EMAIL PROTECTED] wrote:
[...]
Both camps seem to want to allow easy access to the metadata of a
file, whether we're given that file as an inode or as a pathname.
That's why I suggested /meta/vfs and /meta/inode -- sometimes I want
to look up a file by name, and sometimes by
On Mon, Jul 11, 2005 at 10:33:24PM -0400, Horst von Brand wrote:
Hans Reiser [EMAIL PROTECTED] wrote:
I chose '' (four dots) because it clashes with less, not three dots.
Is this some kind of My dots are more than yours contest?!
/None/ of them is safe. .meta, ..., ,
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 with
them. Naturally if some program created a directory called .meta
-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 is in /home/stesmi/.meta/foo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hubert Chan wrote:
> On Thu, 30 Jun 2005 15:52:25 -0400, Horst von Brand <[EMAIL PROTECTED]> said:
>
>
>>>This doesn't even invalidate the userland VFSs of the other guys,
>>>they're still needed for systems whose kernels don't have a metadata
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hubert Chan wrote:
On Thu, 30 Jun 2005 15:52:25 -0400, Horst von Brand [EMAIL PROTECTED] said:
This doesn't even invalidate the userland VFSs of the other guys,
they're still needed for systems whose kernels don't have a metadata
facility.
So
-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 is in /home/stesmi/.meta/foo
Did you mean to reply to the list? I'm taking the liberty of sending
my reply to the list.
On 2005-07-06 17:50:07 -0400 Horst von Brand <[EMAIL PROTECTED]>
wrote:
Hubert Chan <[EMAIL PROTECTED]> wrote:
On Wed, 06 Jul 2005 16:33:23 -0400, Horst von Brand
<[EMAIL PROTECTED]>
said:
Hubert
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
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 detecting
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 detecting cycles
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
Did you mean to reply to the list? I'm taking the liberty of sending
my reply to the list.
On 2005-07-06 17:50:07 -0400 Horst von Brand [EMAIL PROTECTED]
wrote:
Hubert Chan [EMAIL PROTECTED] wrote:
On Wed, 06 Jul 2005 16:33:23 -0400, Horst von Brand
[EMAIL PROTECTED]
said:
Hubert Chan
In article <[EMAIL PROTECTED]>,
David Masover <[EMAIL PROTECTED]> wrote:
>Markus Törnqvist wrote:
>> Anyway, I don't really like the metafs thing.
>>
>> To access the data, you still need to refactor userspace,
>> so that's not a real advantage. Doing lookups from /meta
>> all the time, instead
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
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 and suddenly drowning in
Jonathan Briggs wrote:
>On Tue, 2005-07-05 at 23:44 -0700, Hans Reiser wrote:
>
>
>>Hubert Chan wrote:
>>
>>
>>>And a question: is it feasible to store, for each inode, its parent(s),
>>>instead of just the hard link count?
>>>
>>>
>>>
>>>
>>Ooh, now that is an interesting old idea I
Horst von Brand wrote:
>Hans Reiser <[EMAIL PROTECTED]> wrote:
>
>[...]
>
>
>
>>I think the exokernel approach by Frans is a very interesting approach.
>>I wish I had the experience with it necessary to know if it was
>>effective. I do NOT take the position that name resolution should be in
Doug Wicks wrote:
How do I get off the mail list here?
[EMAIL PROTECTED]
See www.namesys.com, click on "Join Mail List" then in "Unsubscribe
Mailinglist" and follow instructions.
Very difficult, i know.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
Doug Wicks wrote:
How do I get off the mail list here?
[EMAIL PROTECTED]
See www.namesys.com, click on Join Mail List then in Unsubscribe
Mailinglist and follow instructions.
Very difficult, i know.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of
Horst von Brand wrote:
Hans Reiser [EMAIL PROTECTED] wrote:
[...]
I think the exokernel approach by Frans is a very interesting approach.
I wish I had the experience with it necessary to know if it was
effective. I do NOT take the position that name resolution should be in
the kernel. I
Jonathan Briggs wrote:
On Tue, 2005-07-05 at 23:44 -0700, Hans Reiser wrote:
Hubert Chan wrote:
And a question: is it feasible to store, for each inode, its parent(s),
instead of just the hard link count?
Ooh, now that is an interesting old idea I haven't considered in 20
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 and suddenly drowning in
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
In article [EMAIL PROTECTED],
David Masover [EMAIL PROTECTED] wrote:
Markus Törnqvist wrote:
Anyway, I don't really like the metafs thing.
To access the data, you still need to refactor userspace,
so that's not a real advantage. Doing lookups from /meta
all the time, instead of in the
> mount --bind /meta/vfs/some/chroot /some/chroot/meta
This maybe funny if you got 1-2 chrooted applications.
But it will be a nightmare if you got 20-30 chrooted applications.
--
We're working on it, slowly but surely...or not-so-surely in the spots
we're not so sure... -- Larry Wall
-
To
Neil Brown wrote:
On Tuesday July 5, [EMAIL PROTECTED] wrote:
I got it slightly wrong.
One can have hardlinks to a directory without cycles provided that one
does not have hardlinks from the children of that directory to any file
not a child of that directory. (Mountpoints currently
On Wed, Jul 06, 2005 at 09:33:13PM -0500, David Masover wrote:
> And speaking of which, the only doomsday scenario (running out of RAM)
> that I can think of with this scheme is if we have a ton of hardlinks to
> the same file and we try to move one of them. But this scales linearly
> with the
inux-kernel@vger.kernel.org; reiserfs-list@namesys.com;
> [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: Re: reiser4 plugins
>
> David Masover wrote:
>
> > So, will the format change happen at mount time? Will it need a
> > specia
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
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 be navigating to the
Hans Reiser <[EMAIL PROTECTED]> wrote:
[...]
> I think the exokernel approach by Frans is a very interesting approach.
> I wish I had the experience with it necessary to know if it was
> effective. I do NOT take the position that name resolution should be in
> the kernel. I DO take the
Nate Diller wrote:
>
>
> as an example, if a program were to store some things it needs access
> to in its executable's attributes, it should have the option of
> keeping a hard reference to something, so that it can't be deleted out
> from underneath. this enables sane sharing of resources
PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; linux-kernel@vger.kernel.org; reiserfs-list@namesys.com;
[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: reiser4 plugins
David Masover wrote:
>
David Masover wrote:
> So, will the format change happen at mount time? Will it need a
> special mount flag? Will I need to use debugfs or some other offline
> tool?
First we make sure we have the right answer. Have we solved the cycle
problem? Can we run out of memory as Horst/Nikita
On Tue, 2005-07-05 at 23:44 -0700, Hans Reiser wrote:
> Hubert Chan wrote:
> >And a question: is it feasible to store, for each inode, its parent(s),
> >instead of just the hard link count?
> >
> >
> Ooh, now that is an interesting old idea I haven't considered in 20
> years makes fsck more
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 starting
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
On Wed, 06 Jul 2005 14:33:18 -0600, Jonathan Briggs <[EMAIL PROTECTED]> said:
> 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
>>>
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 be
On Wed, 06 Jul 2005 12:52:23 -0600, Jonathan Briggs <[EMAIL PROTECTED]> said:
> On Tue, 2005-07-05 at 23:44 -0700, Hans Reiser wrote:
>> Hubert Chan wrote:
>>> And a question: is it feasible to store, for each
>>> inode, its parent(s), instead of just the hard link count?
>> Ooh, now that is an
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 parent. On the
> > other
Hubert Chan <[EMAIL PROTECTED]> wrote:
> On Wed, 06 Jul 2005 12:52:23 -0600, Jonathan Briggs <[EMAIL PROTECTED]> said:
> > On Tue, 2005-07-05 at 23:44 -0700, Hans Reiser wrote:
> >> Hubert Chan wrote:
> >>> And a question: is it feasible to store, for each
> >>> inode, its parent(s), instead of
On Tue, 05 Jul 2005 22:51:07 -0400, Horst von Brand <[EMAIL PROTECTED]> said:
> 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
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:
If we also add to this the restriction that once you create the file
part of a file-directory, you can never hardlink to a child of it, it
should then all work, yes?
So, /filename//owner should be able to avoid colliding with any
common names by virtue of the '', and
> 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 it.
-
To
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 , and now it
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
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 , and now it is severely crippled?
--
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 currently
Martin Waitz wrote:
>hoi :)
>
>On Tue, Jul 05, 2005 at 04:32:00PM -0600, Jonathan Briggs wrote:
>
>
>>You could do filesystems in userspace too and just use the kernel's
>>block layer.
>>
>>
>
>but you can't do that in an library, you have to use a filesystem
>server in order to get access
On Tue, Jul 05, 2005 at 06:43:31PM -0400, Jeremy Maitin-Shepard wrote:
> > Let's say cryptocompress gets implemented. Not all of userland
> > rewritten, not even any of userland rewritten, just a cryptocompress
> > plugin for the kernel. And instead of having to learn a new tool, I can
> > just
hoi :)
On Tue, Jul 05, 2005 at 04:32:00PM -0600, Jonathan Briggs wrote:
> You could do filesystems in userspace too and just use the kernel's
> block layer.
but you can't do that in an library, you have to use a filesystem
server in order to get access control.
But you can build a library that
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 somewhere!
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 somewhere!
What we
hoi :)
On Tue, Jul 05, 2005 at 04:32:00PM -0600, Jonathan Briggs wrote:
You could do filesystems in userspace too and just use the kernel's
block layer.
but you can't do that in an library, you have to use a filesystem
server in order to get access control.
But you can build a library that
On Tue, Jul 05, 2005 at 06:43:31PM -0400, Jeremy Maitin-Shepard wrote:
Let's say cryptocompress gets implemented. Not all of userland
rewritten, not even any of userland rewritten, just a cryptocompress
plugin for the kernel. And instead of having to learn a new tool, I can
just browse
Martin Waitz wrote:
hoi :)
On Tue, Jul 05, 2005 at 04:32:00PM -0600, Jonathan Briggs wrote:
You could do filesystems in userspace too and just use the kernel's
block layer.
but you can't do that in an library, you have to use a filesystem
server in order to get access control.
But you
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 currently allow users to
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 it is severely crippled?
--
Dr.
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 it is
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
1 - 100 of 170 matches
Mail list logo
