Messages in this thread | | | Date | Thu, 26 Aug 2004 19:05:48 +0200 | From | Diego Calleja <> | Subject | Re: silent semantic changes with reiser4 |
| |
El Thu, 26 Aug 2004 11:54:51 -0400 (EDT) Rik van Riel <riel@redhat.com> escribió:
> And if an unaware application reads the compound file > and then writes it out again, does the filesystem > interpret the contents and create the other streams ?
If the old utils doesn't support streams there's no way to make them create streams. There's not a real solution for that except fixing the old tools.
Why instead of being "compound" you just make test.compound to behave as a real directory? ie:
# echo "foo" > streamfile # echo "fake metadata" > streamfile/somemetadata # cat streamfile foo # cat streamfile/somemetadata fake metadata
Now the old backup utils could see "streamfile" as a directory, ie: old apps could see that "streamfile" is a directory and then make their backups with the following contents: streamfile/somemetadata streamfile/defaultstream
The defaultstream would be what its name means. There could be more default streams like "streamfile/compoundstream"
All this looks like reinventing the file/directory concept wheel. Instead of adding support for streams and "use files as directories", why not orientate it to "use directories as files? Streams could very well be provided by directories containing files, with the addon of being able to cat a directory (which would cat the output of a designed file inside every directory like "defaultstream", then there could be other "special files" like "compoundstream", although the idea of "fixed name- special files" doesn't sounds very cool) All this could be very well provided done userspace, but then couldn't userspace also supply the whole VFS functionality and still it lives in the kernel...?
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |