I'm probably not the first to suggest this idea, and it's probably not a
very good idea, but here's my idea anyhow:
You have a file /usr/bin/emacs
with a metadata property in the overlaid namespace
/usr/bin/emacs/[[..]metas/]icon
According to some, this could cause some confusion. Howabout
I'm probably not the first to suggest this idea, and it's probably not a
very good idea, but here's my idea anyhow:
You have a file /usr/bin/emacs
with a metadata property in the overlaid namespace
/usr/bin/emacs/[[..]metas/]icon
According to some, this could cause some confusion.
On Fri, 2004-09-10 at 06:22, Hans Reiser wrote:
He asked me, why not just access a filename's size as filename/size?
I now understand that you need a way to distinguish between something
like
shoe/size
and
shoe/.../size (or shoe/..size)
The first one is the size of the shoe, the second is
Peter Foldiak wrote:
On Fri, 2004-09-10 at 06:22, Hans Reiser wrote:
He asked me, why not just access a filename's size as filename/size?
I now understand that you need a way to distinguish between something
like
shoe/size
and
shoe/.../size (or shoe/..size)
The first one is the size of
Wichert Akkerman wrote:
Previously Andrew Morton wrote:
But I'll grant that one cannot go adding new metadata to, say, C files this
way. I don't know how useful such a thing is though.
That is actually one of the few places where a bit of metadata would be
very useful. Right now there is no way
Jamie Lokier wrote:
[snip
When a simple cd into .tar.gz or .iso is implemented properly, it
will have _no_ performance penalty after you have first looked in the
file, so long as it remains in the on-disk cache. And, the filesystem
will manage that cache intelligently.
Imagine: for looking at
A friend asked me a question, and because he is very bright it reminded
me that I have not done a good job of reviewing the history of the
design's evolution.
He asked me, why not just access a filename's size as filename/size?
So, the original idea was to access metafiles as just files within
Spam [EMAIL PROTECTED] writes:
Additionally, files-as-directores does not solve the problem of
cp a b losing named streams. There is curently no copyfile syscall
in the Linux kernel, cp a b essentially does cat a b. So unless
cp is modified we don't gain anything. If cp is
Spam [EMAIL PROTECTED] said:
Christer Weinigel [EMAIL PROTECTED] said:
[...]
Could you please try summarize a few of the arguments that you find
especially compelling? This thread has gotten very confused since
there are a bunch of different subjects all being intermixed here.
Spam [EMAIL PROTECTED] said:
Christer Weinigel [EMAIL PROTECTED] said:
[...]
But this still solves only part of the problem. A backup application
won't have any use for a copyfile syscall, it will need to be taught
about streams.
Yes, but backup programs always needed to be taught
Spam [EMAIL PROTECTED] wrote:
One suggestion is missed. It is to provide system calls for copy.
That would also solve the problem.
No, it would not. If you read the POSIX.1 specification for cp
carefully http://www.unix.org/version3/online.html, you will
notice that the process for copying
Spam [EMAIL PROTECTED] wrote:
One suggestion is missed. It is to provide system calls for copy.
That would also solve the problem.
No, it would not. If you read the POSIX.1 specification for cp
carefully http://www.unix.org/version3/online.html, you will
notice that the process
Spam [EMAIL PROTECTED] wrote:
Spam [EMAIL PROTECTED] wrote:
One suggestion is missed. It is to provide system calls for copy.
That would also solve the problem.
No, it would not. If you read the POSIX.1 specification for cp
carefully http://www.unix.org/version3/online.html, you
Horst von Brand wrote:
Spam [EMAIL PROTECTED] said:
Christer Weinigel [EMAIL PROTECTED] said:
[...]
Could you please try summarize a few of the arguments that you find
especially compelling? This thread has gotten very confused since
there are a bunch of different subjects all being
Christer Weinigel wrote:
Spam [EMAIL PROTECTED] writes:
Additionally, files-as-directores does not solve the problem of
cp a b losing named streams.
reiser4 does not support streams, it supports files that can do what
streams do. cp -r does not currently lose files.
Christer Weinigel wrote:
David Masover [EMAIL PROTECTED] writes:
|Second, there are quite a few things which I might want to do, which can
|be done with this interface and without patching programs,
| Such as?
They've been mentioned.
| Haven't seen any that made sense to me, sorry.
Horst von Brand wrote:
Hans Reiser [EMAIL PROTECTED] said:
Horst von Brand wrote:
Spam [EMAIL PROTECTED] said:
Christer Weinigel [EMAIL PROTECTED] said:
[...]
2. How do we want to expose named streams?
One suggestion is file-as-directory in some form.
Hans Reiser [EMAIL PROTECTED] wrote:
Gunnar Ritter wrote:
You cannot just 'modify cp'.
People who think that POSIX is the objective rather than the least
common denominator of OS design
I am not principally adversed against extensions to POSIX. My mailx
implementation 'nail' has e.g.
Pavel Machek wrote:
Hi!
Answer: choose obscure names
Problem (all credit to Mr. Demidov for identifying this problem, I
argued the other viewpoint, and I can only claim the wisdom to know
that I lost the argument): names like ..metas are ugly to new users,
who don't really care for languages
Hi!
What about choosing just ... instead of metas? metas is string
that needs translation etc, while ... is nicely neutral.
cat /sound_of_silence.mp3/.../author
does not look bad, either...
... is pretty good, but I think it has been used by others, but I
really forget who. I could
Hans Reiser [EMAIL PROTECTED] said:
Horst von Brand wrote:
Hans Reiser [EMAIL PROTECTED] said:
Horst von Brand wrote:
Spam [EMAIL PROTECTED] said:
Christer Weinigel [EMAIL PROTECTED] said:
[...]
2. How do we want to expose named streams?
One suggestion is file-as-directory in
Hi!
What if I do not use emacs, but vim, mcedit, gedit, or some other
editor? It doesn't seem logical to have to patch every application
that uses files.
We would have to do that in either case, so let's patch them to do it
in a nonintrusive way. And as to reading and writing
Hi!
Thats how you get yourself a non useful OS. Fix it in a library and
share it between the apps that care. Like say.. gnome-vfs2
Even KIOslave has it. They even support sftp and stuff just by using
shared files in /tmp in reality. That's a much saner interface than
doing it all in
Hi!
What if I do not use emacs, but vim, mcedit, gedit, or some other
editor? It doesn't seem logical to have to patch every application
that uses files.
We would have to do that in either case, so let's patch them to do it
in a nonintrusive way. And as to reading and
Spam [EMAIL PROTECTED] writes:
The problem with the userspace library is standardization. What
would be needed is a userspace library that has a extensible plugin
interface that is standardized. Otherwise we would need lots of
different libraries, and I seriously doubt that 1)
On Thu, Sep 02, 2004 at 10:48:46AM +0100, Alan Cox wrote:
What I don't understand is the tie between Linux having such streams and
Windows doing it for Samba to work. Netatalk has always handle this for
Macintosh and portably. Presumably any Samba support would need to
handle OS's without
On Sat, 4 Sep 2004 05:17, Horst von Brand wrote:
Stuart Young [EMAIL PROTECTED] said:
Hence why I was suggesting the idea of disposable data in streams. As
long as people KNOW it's disposable, but useful to keep around as it cuts
down the time needed to do stuff, then apps will start to
On Iau, 2004-09-02 at 20:41, Spam wrote:
It is trivial to implement this by looking inside the files. I.e., the way
mc has done this for ages.
Difference is that you can't do locate or find or Search.. You
would have to open the files in an archive-supporting application
such
On Iau, 2004-09-02 at 21:01, Lee Revell wrote:
But is it efficient to make every application that reads files have to
know how to get inside a tar file, just to read its contents? That
seems like a massive duplication of effort. Better to have the contents
accessible via a separate stream,
On Iau, 2004-09-02 at 21:07, Spam wrote:
And would you rather that logic was running swappable in shared library
space or privileged and unswappable in kernel ?
I would rather have it as a filesystem/vfs plugin that would allow
all my programs to use the features the plugin gives, even
Alan Cox wrote:
On Mer, 2004-09-01 at 21:16, Jamie Lokier wrote:
(For example, if I edit an HTML file which is encoded in iso-8859-1,
change it to utf-8 and indicate that in a META element, and save it
under the same name, the full content-type should change from
text/html;
On Iau, 2004-09-02 at 21:07, Spam wrote:
And would you rather that logic was running swappable in shared library
space or privileged and unswappable in kernel ?
I would rather have it as a filesystem/vfs plugin that would allow
all my programs to use the features the plugin gives,
Hi!
It is trivial to implement this by looking inside the files. I.e., the way
mc has done this for ages.
Difference is that you can't do locate or find or Search.. You
would have to open the files in an archive-supporting application
such as mc.
And would you rather that
On Thu, 2004-09-02 at 16:43, Pavel Machek wrote:
Hi!
FWIW, this is how Windows does it now. As of XP, 'Find files' has an
option, enabled by default, to look inside archives. If you tell it to
look for a driver in a given directory it will also look inside .cab
and .zip
On Thu, Sep 02, 2004 at 04:47:40PM -0400, Lee Revell wrote:
But how do you cache the information you had to look in the archive
for in a way that other apps can use it?
~/.object-cache/ or whatever
How do you synchronize access to the cache and maintain cache
coherency in userspace?
On Thu, 2004-09-02 at 16:49, Chris Wedgwood wrote:
On Thu, Sep 02, 2004 at 04:47:40PM -0400, Lee Revell wrote:
But how do you cache the information you had to look in the archive
for in a way that other apps can use it?
~/.object-cache/ or whatever
How are permissions handled? If
On Thu, Sep 02, 2004 at 04:57:06PM -0400, Lee Revell wrote:
How are permissions handled? If root lists the contents of a tar
file that is world readable, then joeuser comes along and does the
same, can joeuser sees the cached listing?
everyone has their own cache i guess, works well enough
Hi!
Application does not have to know how to handle tar/zip/etc, but it
has to make distinction between enter archives and do not enter
archives. See uservfs.sf.net.
But how do you cache the information you had to look in the archive for
in a way that other apps can use it? How do you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jamie Lokier wrote:
| David Masover wrote:
|
|Isn't the kernel faced with the same issues here as userland programs
|without meta attribute support? How do you read the META element before
|you know the encoding?
|
|
| Ideally you guess whether it's
On Thu, 2004-09-02 at 23:33 +0100, Alan Cox wrote:
On Iau, 2004-09-02 at 21:58, Pavel Machek wrote:
Uservfs.sf.net.
Unlike alan, I do not think that do it all in library is good
idea. I put it in the userspace as codafs server, and let
applications see it as a regular filesystem.
Jamie Lokier wrote:
Note that file-as-directory doesn't imply that you can store just
anything into those directories.
Is it a problem to decree that file data MUST NOT be stored in a
metadata directory; only non-essential metadata and data computed from
the file data may be stored?
That's
Oh, and if I may notice something more. Just my opinion.
It's going to be 'samba uses only' thing, as long as it's not in VFS.
xattrs are not so much needed as file streams there. So argument that
xattrs exists already in VFS, and are not used, so why do we need
streams there, and that it
Markus Trnqvist wrote:
On Thu, Aug 26, 2004 at 12:32:00AM -0500, Matt Mackall wrote:
Find some silly person with an iBook and open a shell on OS X. Use cp
to copy a file with a resource fork. Oh look, the Finder has no idea
what the new file is, even though it looks exactly identical in the
On Fri, Sep 03, 2004 at 06:43:21AM +0200, Grzegorz Ja??kiewicz wrote:
Then I guess OS X ships a broken implementation of cp, yes?
Nope, GUI handles it perfectly. it's maybe 0.1% of users of MacOS that
acctually care about cp being broken.
Gotta love the Mac logics: Is $FOO broken? - Nope,
[EMAIL PROTECTED] wrote:
On Fri, Sep 03, 2004 at 06:43:21AM +0200, Grzegorz Ja??kiewicz wrote:
Then I guess OS X ships a broken implementation of cp, yes?
Nope, GUI handles it perfectly. it's maybe 0.1% of users of MacOS that
acctually care about cp being broken.
Gotta love the Mac
V13 wrote:
AFAIK and AFAICS the metadata are not files or directories.
Yes they are. In reiser4. They might be stored different, but their
interface is what counts.
On Tue, 31 Aug 2004, Hans Reiser wrote:
You are saying, 1-2% simpler and better, no biggie, why work so hard to
get it?
And we are saying, 1-2% simpler and better, times thousands of
applications, wow! That's a lot!
But would thousands care? Seriously?
For example, you could make
Linus Torvalds wrote:
On Tue, 31 Aug 2004, Hans Reiser wrote:
You are saying, 1-2% simpler and better, no biggie, why work so hard to
get it?
And we are saying, 1-2% simpler and better, times thousands of
applications, wow! That's a lot!
But would thousands care? Seriously?
For
Alexander G. M. Smith wrote:
Hans Reiser wrote on Mon, 30 Aug 2004 23:43:13 -0700:
Alexander G. M. Smith wrote:
Are you sneaking in file types there? Just how does a file know which
plugins it supports?
we have plugins with pluginids, is that what you mean by file type? I
think
On Wed, Sep 01, Jamie Lokier wrote:
And udev _still_ doesn't create device nodes properly. (Hint: I have
to run two modprobe commands before pppd works. I have to run
modprobe before openvpn or bochs work.)
Just because it is supposed to work that way.
--
USB is for mice, FireWire is for
Tonnerre wrote:
I'll write you a small daemon based on libmagic which stores the
file attributes in xattrs, or if they're not supported, in some
MacOS/Xish per-directory files. Even a file manager (finder) can
do that, there's not even the need for a daemon.
Jamie Lokier wrote:
(For
Linus == Linus Torvalds [EMAIL PROTECTED] writes:
[...]
Linus I've seen all these examples of exposing MP3 ID information as a
Linus side stream, and that's TOTALLY POINTLESS! The information is
Linus already there, it's in a standard format, and exporting it as a
Linus stream buys you
Hi!
However, that said, user space can trivially cache things in the
filesystem, so while this may be a convenient feature, I think you should
look at perhaps doing it in the _shell_ instead..
That cache should disappear as soon as I need disk
space. I.e. userspace should never
Spam == Spam [EMAIL PROTECTED] writes:
V13 The only thing that changes (from the userland POV) is the way
V13 someone can enter the 'metadata directory'. This way you don't have
V13 to have a special name, just a special function and no existing
V13 application (like tar) can possibly
Spam == Spam [EMAIL PROTECTED] writes:
Yes. And if we can get file-as-dir, then we only need to patch tar
once, since everything can be exported through that interface.
Spam Yes. This seem to be an acceptable way to do things. But next
Spam time someone comes and want to do changes like
Linus Torvalds [EMAIL PROTECTED] writes:
In a graphical environment, the icon stream is a good example of this.
It literally has _nothing_ to do with the data in the main stream. The
only linkage is a totally non-technical one, where the user wanted to
associate a secondary stream with the
Pavel Machek [EMAIL PROTECTED] writes:
Okay, that does work, it just is not really nice. Just as reserving
fixed ammount of space for disk cache is bad, reserving fixed ammount
of space for ccache (and similar) is bad. When there are few of such
caches, balancing between them starts to
Linus Torvalds [EMAIL PROTECTED] writes:
In a graphical environment, the icon stream is a good example of this.
It literally has _nothing_ to do with the data in the main stream. The
only linkage is a totally non-technical one, where the user wanted to
associate a secondary stream with
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Pavel Machek wrote:
| Hi!
|
|
|| uservfs does
||
|| cd foo.deb#uar
|cd foo.deb/ar
|| vs.
|| cd foo.deb#udeb
|cd foo.deb/deb
|
|and why would you want that, instead of just:
|cd foo.deb # for the ar
|dpkg -i foo.deb# for the deb
|
|
| Because I want
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Horst von Brand wrote:
| Pavel Machek [EMAIL PROTECTED] said:
|
|David Masover [EMAIL PROTECTED] said:
|
|
| [...]
[...]
| You do need extra tools anyway, placing them in the kernel is cheating
(and
| absolutely pointless, IMHO).
Repeat after me:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christer Weinigel wrote:
| Pavel Machek [EMAIL PROTECTED] writes:
|
|
|Okay, that does work, it just is not really nice. Just as reserving
|fixed ammount of space for disk cache is bad, reserving fixed ammount
|of space for ccache (and similar) is bad.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hans Reiser wrote:
| David Masover wrote:
|
|
|
| And I did mention before about how it'd be nice for it to be an fs
| chunk...
|
|
| Please define fs chunk. My mind has an open door.;-)
I think this is sort of like dump/restore, but for a subset of
On Tuesday 31 August 2004 21.38, Spam wrote:
Salut,
On Tue, Aug 31, 2004 at 08:17:36PM +0200, Spam wrote:
How are things done on Windows platforms when there are files and
directories with the same name? In Unix that is imposible. How does
it work for environments like
Hans Reiser wrote on Mon, 30 Aug 2004 23:43:13 -0700:
Alexander G. M. Smith wrote:
Are you sneaking in file types there? Just how does a file know which
plugins it supports?
we have plugins with pluginids, is that what you mean by file type? I
think they are a bit different from file
Hi!
| You do need extra tools anyway, placing them in the kernel is cheating
(and
| absolutely pointless, IMHO).
Repeat after me: plugins in kernel does NOT equal tools in kernel.
It's not hard to, for instance, imagine a generic plugin for archive
manipulation which talks to a
Hi!
I belive the kernel could give some assistance to make it easier to
see if a file has been modified, I remember that a few suggestions
were thrown around the last time Samba and dcache aliases were
discussed on l-k. I definitely belive that kind of infrastructure
belongs in the kernel.
Linus, you are looking at this like a lieutenant instead of an HQ
staffer, which is unusual of you.
You are saying, 1-2% simpler and better, no biggie, why work so hard to
get it?
And we are saying, 1-2% simpler and better, times thousands of
applications, wow! That's a lot!
Yes, changing
On Sun, Aug 29, 2004 at 05:05:17PM -0400, Hubert Chan wrote:
Reiserfs list, and I don't think there was much consensus that came out
It's like Gentoo users and patch sets ;)
of it. Currently for Reiser4, AFAIK, the metas name is a compile-time
option that you can change by changing a #define,
On Mon, Aug 30, 2004 at 05:46:37AM +0100, [EMAIL PROTECTED] wrote:
Arguments about O_NOFOLLOW on the intermediate stages are bullshit, IMNSHO -
if they want to make some parts of tree inaccessible, they should simply
mkdir /tmp/FOAD; chmod 0 /tmp/FOAD; mount --bind /tmp/FOAD blocked path
in
I think we have to either:
1) Link only to the file and not the directory in the file-directory
duality. This means we change the semantics of hard link so that it only
links to the data and the standard metadata, and the optional
attributes/streams/files-in-directory are not seen by the second
The Idea
You should be able to access metadata about a file the same way you
access the file's data, but with a name based on the filename followed
by a name to select the metadata of interest.
Examples:
cat song_of_silence/metas/owner
cat song_of_silence/metas/permissions
cat 10
Helge == Helge Hafting [EMAIL PROTECTED] writes:
Helge Linus Torvalds wrote:
[...]
That doesn't really help us. What would the name be, and how could you
avoid clashes?
Helge The name for the file stream and the directory would be the same,
Helge distinguished by how they're used. I.e.
Hans Reiser wrote on Sun, 29 Aug 2004 13:21:44 -0700:
The Idea [...] Conclusion
Good summary!
The Idea 2: [...]
cat filename/pseudos/backup gives a set of commands that a backup
command can use to create the file filename [...]
Are you sneaking in file types there? Just how does a file
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Pavel Machek wrote:
[...]
| uservfs does
|
| cd foo.deb#uar
cd foo.deb/ar
| vs.
| cd foo.deb#udeb
cd foo.deb/deb
and why would you want that, instead of just:
cd foo.deb # for the ar
dpkg -i foo.deb # for the deb
|
| and
|
| cd foo.tgz#utar
cd
Hans Reiser wrote:
I think there are two ways to analyze the code boundary issue. One is
does it belong in the kernel? Another is, does it belong in the
filesystem. and if so should name resolution in a filesystem be split
into two parts, one in kernel, and one in user space. In ten years I
Linus Torvalds wrote:
On Sat, 28 Aug 2004, Hans Reiser wrote:
I object to openat().
Sound slike you object to O_XATTRS, not openat() itself.
Realize that openat() works independently of any special streams, it's
fundamentally a look up name starting from this file (rather than
starting
Hello,
This thread is very very very very big. I think lots of people spend
hours talking here. Isn't it time for a summary of all this please ?
(for people like me who are quite busy and try to follow... but also for
the health of the debate)
Thank!
Mikael.
On Sun, Aug 29, 2004 at 02:36:50AM -0700, Hans Reiser wrote:
Linus Torvalds wrote:
On Sat, 28 Aug 2004, Hans Reiser wrote:
I object to openat().
Sound slike you object to O_XATTRS, not openat() itself.
Realize that openat() works independently of any special streams, it's
On Thu, Aug 26, 2004 at 04:04:34PM +0100, Jamie Lokier wrote:
Christophe Saout wrote:
What reiser4 can do, but the VFS can't is to insert or remove data in
the middle of a file. Adding this above the page cache would probably be
almost impossible (truncate seems already complicated enough).
On Sat, Aug 28, 2004 at 12:46:10PM -0700, Linus Torvalds wrote:
Now there is no attribute space, just a shorthand.
It's more than a shorthand, though. _Much_ more.
...
Both of those are why it would need special support.
Yes - support, I do not argue against that.
But I argue against an
Rik van Riel [EMAIL PROTECTED] said:
On Thu, 26 Aug 2004, Linus Torvalds wrote:
So /tmp/bash is _not_ two different things. It is _one_ entity, that
contains both a standard data stream (the file part) _and_ pointers to
other named streams (the directory part).
Thinking about it some
Spam [EMAIL PROTECTED] said:
Chris Wedgwood wrote:
[...]
Gnome, KDE, Emacs and Bash all see different virtual filesystems.
(All but Bash implement their own virtual filesystem extensions).
That makes them much less useful than they could be.
Exactly, and I doubt they have
On Sun, Aug 29, 2004 at 07:31:49PM -0700, Linus Torvalds wrote:
On Sun, 29 Aug 2004, Trond Myklebust wrote:
- how to actually test this out in practice (ie getting reiser4 to do the
proper thing wrt the VFS layer, but preferably _also_ having another
filesystem like NFSv4 or cifs
I am thinking that is there was a proper API for accessing the
filesystem then this problem wouldn't arise because things could be
done behind the curtains inside the API, instead of having all the
tools to be rewritten to know.
Think of FAT32, for example, the new filenames
Hi!
Yes, but I didn't say flame Christoph and ignore the issues ;)
Oh;-)
...
enhancements. This metafiles and file-directories stuff is actually
fairly trivial stuff.
Now I'm scared.
not as powerful. Don't
move reiser4 into vfs, use reiser4 as the vfs. Don't write
Hi!
One of the big potential uses for file-as-directory is to go inside
archive files, ELF files, .iso files and so on in a convenient way.
Arguably this belongs in userspace --- and people have put it there.
I agree that these belong in userspace, and that there's plenty* of
On Sat, 28 Aug 2004, Hans Reiser wrote:
I object to openat().
Sound slike you object to O_XATTRS, not openat() itself.
Realize that openat() works independently of any special streams, it's
fundamentally a look up name starting from this file (rather than
starting from root or starting
On Sat, 28 Aug 2004 [EMAIL PROTECTED] wrote:
OK, forget getcwd(). What does lookup of .. do from that point? *Especially*
for stuff you've got from regular files. That's the decision that needs to
be made.
I think that will decide on whether we expose attributes through the
normal
On Sat, Aug 28, 2004 at 10:12:39PM -0700, Linus Torvalds wrote:
If we do expose them in the normal namespace, then .. should work the
way the namespace looks: if you do .. on the attribute directory of a
file, you get the directory that the file was in. Ie an old-style
user-space getcwd()
Christoph Hellwig wrote:
On Fri, Aug 27, 2004 at 02:03:36AM +0400, Nikita Danilov wrote:
What about fs/reiser4/plugin/node/ and fs/reiser4/plugin/disk_format/?
Of course you can implement another filesystem inside the plugins but
they wouldn't use fs/reiser4/*.c, so this would be rather
Linus Torvalds wrote:
To me, a filesystem that allows this thing doesn't really _have_ the
concept of directory vs file. It's just a filesystem object, and it
can act as _both_ a directory and a file.
I agree.
On Thu, 2004-08-26 at 21:54, Linus Torvalds wrote:
The S_ISDIR/S_ISREG tests show real information: it shows not only user
intent (you should consider this a file, even if it has attributes), but
also whether it is a directory or a container.
And there's a real technical difference there:
[EMAIL PROTECTED] wrote:
On Thu, Aug 26, 2004 at 04:47:39PM -0700, Hans Reiser wrote:
Sometimes you want the nonlocal effects and sometimes you don't, and by
decomposing streams into smaller primitives we can let users choose as
they want.
Right. Now, would you kindly post the detailed
Linus Torvalds wrote:
No no. The stream you get from a directory is totally _independent_ of the
contents of the directory.
but the user can link filename/metas/body to filename/metas/tar, if we
implement a tar plugin, if it happens that the user wants it to be
totally dependent.
Anything
On Thu, Aug 26, 2004 at 11:55:07AM -0700, Linus Torvalds wrote:
On Thu, 26 Aug 2004, Rik van Riel wrote:
So you'd have both a file and a directory that just happen
to have the same name ? How would this work in the dcache?
There would be only one entry in the dcache. The lookup
On Fri, Aug 27, 2004 at 09:41:07AM +0200, Bernd Petrovitsch wrote:
UNIX doesn't have a copy systemcall, applications copy the data
manually.
Oh, this is very unfortunate and should be a bigger issue to fix.
Then you have to rewrite POSIX und SuSv3.
They don't say 'you must now
On Fri, Aug 27, 2004 at 01:05:02AM -0700, Hans Reiser wrote:
Spam is right. Posix is a standard, not a vision, and the future is
always a vision not a standard.
An old friend of mine always said if someone has visions he needs to
stop somking mushrooms..
On Fri, Aug 27, 2004 at 01:12:44AM -0700, Hans Reiser wrote:
Your arrogance is misplaced for a man who has never done a significant
piece of research.
Christoph, we are doing work, you are in the way, get out of the way.
Could you please stop the namecalling. And if you want to check who
On Fri, 2004-08-27 at 10:49 +0200, Christoph Hellwig wrote:
On Fri, Aug 27, 2004 at 09:41:07AM +0200, Bernd Petrovitsch wrote:
UNIX doesn't have a copy systemcall, applications copy the data
manually.
Oh, this is very unfortunate and should be a bigger issue to fix.
Then
On Thu, Aug 26, 2004 at 04:53:51PM -0700, Hans Reiser wrote:
If the early linux filesystems had taken the same attitude you have
(don't write new filesystems, only write plugins), there would be no
framework allowing the wealth of filesystems we do have, including
reiser4.
Au
1 - 100 of 195 matches
Mail list logo
