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
-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.
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
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
-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
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
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
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
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.
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
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
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
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.
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
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
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.
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
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
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
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 position
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 file
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 without
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 robust
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 interesting
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 and
every file
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 hand,
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 just the hard link
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
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 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 from A. If
PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: reiser4 plugins
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
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:
So
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
;
[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
special mount flag? Will I need to use debugfs or some other offline
tool?
First we make sure
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
hoi :)
On Wed, Jun 29, 2005 at 08:04:58PM -0700, Hans Reiser wrote:
How is directories as files logically any different than putting all
data into .data files and making all files directories (yes you would
need some sort of special handling for files that were really called
.data).
Add
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 the metadata facility in kernel won't be used, for portability's
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 annotate arbitrary files.
I can very well
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 into the mainline kernel. (Of course, the latter
doesn't
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 into the mainline kernel.
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 into
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
On Tue, 2005-07-05 at 17:46 +0200, Martin Waitz wrote:
[snip]
Filesystems are there to store files.
Everything else can be done in userspace.
You could do filesystems in userspace too and just use the kernel's
block layer.
In fact you can reduce the OS kernel to just interrupts, memory
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?) issues. And, of
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?)
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 linking of metafiles. Maybe some years from now
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 implement that
restriction.)
Question: can one implement that lesser
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 not letting any
Hans Reiser wrote on Tue, 05 Jul 2005 16:56:02 -0700:
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 implement that
restriction.)
Question:
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 want is no directed cycles.
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 implement that
On Monday 04 July 2005 05:42, Hans Reiser wrote:
Horst von Brand wrote:
Right. But, /proc started somewhere, didn't it?
Sun.
No, plan 9.
Actually, I heard a lecture on implementing /proc in BSD at least 5 years
earlier than plan 9.
It seems to me that what you are all arguing about is
malcolm wrote:
On Monday 04 July 2005 05:42, Hans Reiser wrote:
Horst von Brand wrote:
Right. But, /proc started somewhere, didn't it?
Sun.
No, plan 9.
Actually, I heard a lecture on implementing /proc in BSD at least 5 years
earlier than plan 9.
On Sun, Jul 03, 2005 at 08:42:24PM -0700, Hans Reiser wrote:
Right. But, /proc started somewhere, didn't it?
Sun.
No, plan 9.
Almost on the right track, it was v8, two steps before plan9. But that's
just the process-part of procfs, not the big mess we have now - that part
is
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
; Christoph Hellwig; Andrew Morton; linux-kernel@vger.kernel.org;
ReiserFS List
Subject: Re: reiser4 plugins
Horst von Brand wrote:
Right. But, /proc started somewhere, didn't it?
Sun.
No, plan 9.
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 beneficial to me
How, exactly?
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 some separate tool
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 userland VFS anyway.
Adding
Le Fri, 01 Jul 2005 04:08:20 -0500, David Masover [EMAIL PROTECTED] a écrit :
Hi all,
Metafs also avoids having to patch tar. It's assumed that legacy backup
systems can always avoid metafs and still catch almost everything
important, and certainly everything they already do catch. With a
Pierre Etchemaïté wrote:
Le Fri, 01 Jul 2005 04:08:20 -0500, David Masover [EMAIL PROTECTED] a écrit :
Hi all,
Metafs also avoids having to patch tar. It's assumed that legacy backup
systems can always avoid metafs and still catch almost everything
important, and certainly everything they
Horst von Brand wrote:
Kevin Bowen [EMAIL PROTECTED] wrote:
[...]
The desire
amongst users for ubiquitous metadata is very real - the current wave of
desktop search products and technologies demonstrates this -
Just like each
Dmitry Torokhov wrote:
On 6/30/05, Theodore Ts'o [EMAIL PROTECTED] wrote:
On Mon, Jun 27, 2005 at 04:12:38PM -0500, David Masover wrote:
Streamload cannot warrant and does not guarantee, and You
should not expect, that all of Your private communications and
other personal
Zan Lynx wrote:
On Thu, 2005-06-30 at 14:47 -0400, Horst von Brand wrote:
[snip]
[snip-some-more]
Structured files are fine when they're small but quickly become
disgusting as they get bigger. Either you slowly rewrite the whole
thing or you fast save by writing new sections to the end of it
Horst von Brand wrote:
Kevin Bowen [EMAIL PROTECTED] wrote:
and think
about it just limited to a user's home directory, and the storage and
organization of actual *data* (as opposed to system files).
Who is to say what is data
Hubert Chan wrote:
On Thu, 30 Jun 2005 08:29:56 +0200, David Weinehall [EMAIL PROTECTED] said:
On Thu, Jun 30, 2005 at 12:33:10AM -0400, Hubert Chan wrote:
It's sort of like the way web servers handle index.html, for those
who think it's a stupid idea. (Of course, some people may still
Hubert Chan wrote:
On Wed, 29 Jun 2005 17:34:41 -0400, Ross Biro [EMAIL PROTECTED] said:
I'm confused. Can someone on one of these lists enlighten me?
How is directories as files logically any different than putting all
data into .data files and making all files directories (yes you
Wow. Good that you noticed it. It sounds like they have the business
model of an intelligence agency.
Hans
Theodore Ts'o wrote:
If you are using the free service, and are encrypting the data, you
are explicitly violating their terms of service, and they can delete
your data at any time,
Dmitry Torokhov wrote:
If you are using the free service, and are encrypting the data, you
are explicitly violating their terms of service, and they can delete
your data at any time, once they notice.
Does not look like it:
3c. No encryption and/or steganography for the purpose of
David Weinehall wrote:
On Wed, Jun 29, 2005 at 04:58:20PM +0300, Markus Törnqvist wrote:
On Wed, Jun 29, 2005 at 09:50:27AM -0400, Douglas McNaught wrote:
I'll just note that the applications bundled as directories stuff on
MacOS/NextStep is done completely in userspace--as far as the
Horst von Brand wrote:
Markus Törnqvist [EMAIL PROTECTED] wrote:
[...]
Note that MacOS has the monopoly on what they ship, Linux has a
motherload of file managers and window systems and all.
Yep. Part of what is nice about it, too ;-)
What pisses me off is the fact that Gnome and
It was always the expectation that users would want to have one
mountpoint with the files having metafiles as files, and another with
the same files but strictly posix, and then their apps can use whichever
they have the power to understand.
Hans
David Masover wrote:
Hubert Chan wrote:
On
Hans Reiser wrote:
It was always the expectation that users would want to have one
mountpoint with the files having metafiles as files, and another with
the same files but strictly posix, and then their apps can use whichever
they have the power to understand.
It was never in the early betas I
David Masover wrote:
Hans Reiser wrote:
It was always the expectation that users would want to have one
mountpoint with the files having metafiles as files, and another with
the same files but strictly posix, and then their apps can use whichever
they have the power to understand.
It was
Hubert Chan wrote:
On Tue, 28 Jun 2005 15:22:55 -0500, David Masover [EMAIL PROTECTED] said:
Come to think of it, that changes the proposal a bit. You need a
different way to access the meta-dir for files than for directories,
if we're going to support /meta/vfs. No biggie:
Hubert Chan wrote:
On Tue, 28 Jun 2005 15:59:03 -0400, Kyle Moffett [EMAIL PROTECTED] said:
On Jun 28, 2005, at 13:51:04, Hubert Chan wrote:
I don't know if VFS is the right place for it, but I agree that it
would be good to make it accessible to all filesystems.
That's somewhat of a
Rule #3 from http://www.streamload.com/About/Legal_eng.asp?page=id73#
is pretty clear about what applies if you have a trial account (which
seems to be what you have since you say you'll cancel your account if
they charge you anything):
3. Do not circumvent Freeloader download restrictions.
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 userland VFS anyway.
Adding this to the Linux kernel won't help them one bit, unless
we can
Theodore Ts'o wrote:
Rule #3 from http://www.streamload.com/About/Legal_eng.asp?page=id73#
is pretty clear about what applies if you have a trial account (which
seems to be what you have since you say you'll cancel your account if
they charge you anything):
3. Do not circumvent Freeloader
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 userland VFS anyway.
Adding this to the Linux kernel won't help them
1 - 100 of 374 matches
Mail list logo
