Re: [reiserfs-list] When will Reiserfs be ready?
> According to Mandrake people you can't reliably write to Win2K/XP NTFS > partitions. > > Of course that doesn't change the fact that Nast's original posting of > "don't use NT because you can't write to it" is wrong. Windows NT 4.0 (the > last version to be called "NT" ) has a format that can be written by Linux. When I write NT I mean to include all its direct descendants, like Win2000 and XP. When I read Reiser is stable, I conclude that Reiser4(when released) is stable. Hans wrote: "(Should I go from FAT32 to NTFS on my laptop windows partition? Fear of performance loss has kept me from doing so.)" What windows OS supports BOTH FAT32 and NTFS???!!! Windows 2000 and XP. Not NT4. Read this OFFICIAL Microsoft Knowledge base article which includes: "NOTE : Microsoft Windows NT 4.0 does not support the FAT32 file system." @http://support.microsoft.com/default.aspx?scid=kb;EN-US;q154997 Regards, _nasturtium
Re: [reiserfs-list] Re: magic is useless & Determining File Types
>If the kernel people can't fit it in, it can be hacked around. >Perhaps have each object appear twice in directory listings (once >as a file, once as a directory, perhaps with a slightly different >name). Or have an alternate API via ioctl codes until it gets >accepted as being worthy of the kernel. How about making the trailing slash on a file name significant? If you open "myfile" you get the file's data, but if you opendir "myfile/" then you get the directory of its attributes and sub-objects. For the hack, have the directory listing include entries "file" and "file/". That would possibly break some code with double slashes in path names due to composing the directory path with a subdirectory, such as "file//content-type". But if the OS removed double slashes or treated them as single, then it could work. - Alex
Re: [reiserfs-list] Re: magic is useless & Determining File Types
On Sat, Jan 12, 2002 at 07:48:23PM +0100, Xuan Baldauf wrote:
> > Why would they rely on using foo.jpeg/thumbnail.png, as opposed to
> > foo.jpeg/thumbnail.png/content?
>
> Because there is a contract between the application and the filesystem that some
> entity (e.g. a file) can be found again using the same name which was used on
> creation of that entity.
I agree, but I don't see how this is inconsistent.
If you just store "thumbnail.png" (as opposed to thumbnail/content),
then there is no possibility of adding attributes.
> > Why not support both options? If a file is a file, it's a file. (*grin*)
> > If a file is a directory with /content, then it's also a file ;)
>
> That's my point. If attributes of files are implemented as directories, accessing
> those files with attributes must be downward compatible. If redirecting an
>
> open("foo.jpeg");
>
> to an
>
> open("foo.jpeg/content");
>
> within the kernel if foo.jpeg got changed to be an directory is possible and
> efficient, that could be okay from that viewpoint.
It seems better to implement this in user space. libgnomevfs, or something
like that.
> > What does "name" mean in this context?
>
> The text string to access the same data which was stored using the same name some
> time ago. So requiring the application to change
>
> open("foo.jpeg");
>
> to
>
> open("foo.jpeg/content");
All problems in software engineering can be solved by adding another
layer of indirection TM
Basically: on the shell, etc., I want to see foo/content as a directory
containing a file. When I use GNOME, I want to be able to see it both
ways. For applications that don't adopt this, no big deal... just pass
them file/content, instead of file.
Andrew
Re: [reiserfs-list] Re: magic is useless & Determining File Types
"Alexander G. M. Smith" wrote: > Hubert Chan <[EMAIL PROTECTED]> wrote on 11 Jan 2002 20:44:44 -0500: > > I think that's the point of trying to figure out a prefix for the > > attributes -- so that attribute names in directories won't collide with > > file names. So if you want a thumbnail for your directory foo, you just > > do "cp icon.png foo/..thumbnail". (No special tools needed! Unifying > > namespaces is great!) > > Why do we need to distinguish between attributes and files? We > don't have to, or at least the file system doesn't have to (well, > except for underlying indexability). Well, traditional files have stat_data defined for them (these is the traditional fixed metadata). If we make attributes files with stat_data, we'd create unneccessary stat_data (like Hubert's "foo.png/..creation-date/..creation-date/..creation-date"). So we should not define stat_data for all attributes (but maybe for some attributes like "foo.png/..thumbnail.png"). Xuân. -- Mit freundlichen Grüßen Xuân Baldauf Medium.net Internet Server Software
Re: [reiserfs-list] Re: magic is useless & Determining File Types
toad wrote: > On Sat, Jan 12, 2002 at 04:30:16PM +0100, Heinz-Josef Claes wrote: > > Am Fre, 2002-01-11 um 18.59 schrieb Jens Benecke: > > > On Mon, Jan 07, 2002 at 12:46:22PM +0300, Hans Reiser wrote: > > > > > > > Let us get a bit more specific. You should echo "text/plain" > > > > > /etc/passwd/..mime-type > > > > > > >> I don't mind a prefix as long as it doesn't break anything else. If you > > > >> use '..' as a prefix that would break creating files that start with two > > > >> dots. I don't know why anyone would ever want to do that but it is > > > >> possible now, and it should stay possible, otherwise you risk endless > > > >> flame wars about people having to rewrite scripts or applications or > > > >> whatever. > > > > We know from experience with Clearcase and NetApp filers that reserving > > > > some of the namespace is not really so bad. Users survive it. > > > > > > Yes, the problems come when you migrate an existing setup to the > > > metadata-capable Reiser file system. > > > > > > One way around this might be an additional attribute that specifies whether > > > metadata exists. If it isn't set, then all chars are allowed in the file > > > name. If it is, then e.g. disallow "#" (or something more complex like > > > "#attr:") as part of a file name and treat strings behind it like a > > > metadata attribute. > > > > > > > > > However these are just crude workaround hacks that I don't really like > > > either. IMHO, we really need an additional layer between the file system > > > and the "desktop" (which includes bash & Co.) / end-user, which handles the > > > metadata operations. > > > > > > But we also need to convince just about every Unix programmer on the world > > > to use them, to become useful for all. Storing Content-Type in an EA and > > > forgetting about file extensions can become a major PITA if every second FS > > > (or transfer method, see FTP, Samba) you come across doesn't support EAs. > > > > > > > > It's even more than basch, ftp. samba and so on. Imagine the following: > > You tar several files, then gzip the tar file. Following, you tar the > > resulting tar.gz file with others in a cpio (or tar) to back it up or > > transfer it via rsh. As you see, the process of _storing_ content type > > must be recursive and supported in every program dealing with files > > (like netscape when storing). > > What about breaking compatibility of tar, cpio, gzip, bzip2, etc. with > > other operating systems?? > gzip, bzip2 - huh? > Only tar and cpio need to know about this stuff No, gzip and bzip2 are stream compressors, but they compress files, too. The gzip-Format even allows writing the filename of the uncompressed file into the compressed stream. If you see gzip and bzip2 as file compressors, and files have attributes, they have to transport those attributes, too in order to have an exact copy of the original file. Xuân. > > > > > I think, it's a nice idea, but difficult and perhaps unrealistic. > > > > just my 2cents > > Heinz-Josef Claes > > [EMAIL PROTECTED] > > > > > > > -- > > > mfg, Jens Benecke > > > http://www.jensbenecke.de/ - Pers?nliches > > > http://www.hitchhikers.de/ - Europas Mitfahrzentrale (car sharing agency) > > > > > > Politics is like a septic tank - all the big shits float to the top. > > > > -- > The road to Tycho is paved with good intentions > > >Part 1.2Type: application/pgp-signature -- Mit freundlichen Grüßen Xuân Baldauf Medium.net Internet Server Software
Re: [reiserfs-list] Re: magic is useless & Determining File Types
Andrew Clausen wrote:
> On Sat, Jan 12, 2002 at 03:32:00PM +0100, Xuan Baldauf wrote:
> > Following the approach, you'd have to use those names:
> >
> > foo.jpeg/content
> > foo.jpeg/content-type
> > foo.jpeg/thumbnail.png/content
> > foo.jpeg/thumbnail.png/content-type
> >
> > But this would not be compatible with the same approach above of naming
> > metadata like this:
> >
> > foo.jpeg/content
> > foo.jpeg/thumbnail.png
> >
> > Applications relying on finding the thumbnail using the name
> > "foo.jpeg/thumbnail.png" would not find it anymore.
>
> Why would they rely on using foo.jpeg/thumbnail.png, as opposed to
> foo.jpeg/thumbnail.png/content?
Because there is a contract between the application and the filesystem that some
entity (e.g. a file) can be found again using the same name which was used on
creation of that entity.
>
>
> BTW: why not foo/thumbnail/content? No point saying it's a jpeg twice
> (in the filename, and the subdirectory)
>
> > One could define that any metadata which has the chance to get metadata for
> > itself has to be named in form of "${directory}/content", but you do not know
> > in advance to which extend this applies to which metadata, so you would have
> > to represent all data in that form (because all data is metadata in the sense
> > of it's application, because all data states something about something),
> > converting files into deep directory structures on the filesystem level. This
> > would result in a tree-structured store of data (aka XML database). But this
> > concept is too far, (and maybe too inefficient and complicated if mapped onto
> > directories this way).
>
> Why not support both options? If a file is a file, it's a file. (*grin*)
> If a file is a directory with /content, then it's also a file ;)
That's my point. If attributes of files are implemented as directories, accessing
those files with attributes must be downward compatible. If redirecting an
open("foo.jpeg");
to an
open("foo.jpeg/content");
within the kernel if foo.jpeg got changed to be an directory is possible and
efficient, that could be okay from that viewpoint.
>
>
> > That is why you should not make a difference between the names of files and
> > the names of files with attributes. If you do it, you do it like it is done in
> > the programming language BASIC, where string variables are denoted as
> > "variableName$" while integer variables are denoted as "variableName" (without
> > the '$' mark). This is making the name of a file|variable dependent of it's
> > type (in this case: real file or directory).
>
> What does "name" mean in this context?
The text string to access the same data which was stored using the same name some
time ago. So requiring the application to change
open("foo.jpeg");
to
open("foo.jpeg/content");
internally is bad. The same data should be accessible using the same name as long it
is desired (e.g. it is not renamed or unlinked by the user), independent of the
filesystem internals (as wether or not a file has attributes). You also do not
change names if a file is reordered on disk (uses other blocks). You even should not
need to change names if files are moved to another partition. (This problem is
currently manually fixed with symlinks, but in reality, the user should not be
required to fix this manually, the user should merely plug and unplug disks time by
time and say that which files should reside where, distributing should be automatic.
LVM or RAID do not solve this because if two disks are split from each other, none
will be usable.)
> How it's stored ondisk?
That's irrelevant from the semantic|"contract"-viewpoint. :-)
> How it's addressed? (how it's addressed through syscalls? The GIMP?)
How are file names addressed? I do not properly understand your question. :-( (Files
are addressed using file-operations like open() etc.)
>
>
> Andrew
Xuân.
--
Mit freundlichen Grüßen
Xuân Baldauf
Medium.net Internet Server Software
Re: [reiserfs-list] Attributes and Metadata about Metadata
On Sat, Jan 12, 2002 at 11:56:21AM -0500, Alexander G. M. Smith wrote:
> toad <[EMAIL PROTECTED]> wrote on Sat, 12 Jan 2002 01:07:20 +:
> >> The implementation detail is that the attribute/file/object type has
> >> to be a special case, not a generic attribute. Perhaps a 32 bit integer
> >> hidden in the underlying inodes. [...]
> >
> > A {sym,hard,COW}link?
>
> What's a COW link? I'm familiar with copy-on-write, but that's a virtual
> memory term. Is it like a MacOS alias?
It's like a link, but when you modify the file the file gets copied. Possibly
implemented on a per-block basis rather than whole-file. Discussed in the
archives; Win2K server has something like this.
>
> - Alex
--
The road to Tycho is paved with good intentions
msg03958/pgp0.pgp
Description: PGP signature
Re: [reiserfs-list] Re: magic is useless & Determining File Types
On Sat, Jan 12, 2002 at 04:30:16PM +0100, Heinz-Josef Claes wrote: > Am Fre, 2002-01-11 um 18.59 schrieb Jens Benecke: > > On Mon, Jan 07, 2002 at 12:46:22PM +0300, Hans Reiser wrote: > > > > > Let us get a bit more specific. You should echo "text/plain" > > > > /etc/passwd/..mime-type > > > > >> I don't mind a prefix as long as it doesn't break anything else. If you > > >> use '..' as a prefix that would break creating files that start with two > > >> dots. I don't know why anyone would ever want to do that but it is > > >> possible now, and it should stay possible, otherwise you risk endless > > >> flame wars about people having to rewrite scripts or applications or > > >> whatever. > > > We know from experience with Clearcase and NetApp filers that reserving > > > some of the namespace is not really so bad. Users survive it. > > > > Yes, the problems come when you migrate an existing setup to the > > metadata-capable Reiser file system. > > > > One way around this might be an additional attribute that specifies whether > > metadata exists. If it isn't set, then all chars are allowed in the file > > name. If it is, then e.g. disallow "#" (or something more complex like > > "#attr:") as part of a file name and treat strings behind it like a > > metadata attribute. > > > > > > However these are just crude workaround hacks that I don't really like > > either. IMHO, we really need an additional layer between the file system > > and the "desktop" (which includes bash & Co.) / end-user, which handles the > > metadata operations. > > > > But we also need to convince just about every Unix programmer on the world > > to use them, to become useful for all. Storing Content-Type in an EA and > > forgetting about file extensions can become a major PITA if every second FS > > (or transfer method, see FTP, Samba) you come across doesn't support EAs. > > > > > It's even more than basch, ftp. samba and so on. Imagine the following: > You tar several files, then gzip the tar file. Following, you tar the > resulting tar.gz file with others in a cpio (or tar) to back it up or > transfer it via rsh. As you see, the process of _storing_ content type > must be recursive and supported in every program dealing with files > (like netscape when storing). > What about breaking compatibility of tar, cpio, gzip, bzip2, etc. with > other operating systems?? gzip, bzip2 - huh? Only tar and cpio need to know about this stuff > > I think, it's a nice idea, but difficult and perhaps unrealistic. > > just my 2cents > Heinz-Josef Claes > [EMAIL PROTECTED] > > > > -- > > mfg, Jens Benecke > > http://www.jensbenecke.de/ - Pers?nliches > > http://www.hitchhikers.de/ - Europas Mitfahrzentrale (car sharing agency) > > > > Politics is like a septic tank - all the big shits float to the top. > -- The road to Tycho is paved with good intentions msg03957/pgp0.pgp Description: PGP signature
Re: [reiserfs-list] Re: magic is useless & Determining File Types
On Jan 11, 2002 19:59 -0500, Hubert Chan wrote: > Andrew> Perhaps file(1) should know about such packages, and call an > Andrew> extracter, and reinvoke itself? > > Yes, so then we need to write another extension to file(1)... > file also doesn't seem to (currently) handle uncompressing files, and > checking the type of the decompressed contents, so that's another > extension that needs to be written. Well, "file -z" should do this already. > schedule.tex: LaTeX 2e document text > schedule.tex: text/x-c++; charset=us-ascii > > I guess I can give this to them, since the file with no -i gave a > correct answer. The discrepancy is strange, though, and perhaps it > illustrates the hardness in keeping a correct set of databases? Well, part of the issue is that "file -i" uses a different (much smaller) magic file, so it may be that the LaTeX magic is not in there yet. Granted, magic is not foolproof (as we all know), but it is mostly good enough, and if it would (in addition, probably as an option) use the file extension to help classify some files that would be best. Cheers, Andreas -- Andreas Dilger http://sourceforge.net/projects/ext2resize/ http://www-mddsp.enel.ucalgary.ca/People/adilger/
Re: [reiserfs-list] Re: magic is useless & Determining File Types
Hubert Chan <[EMAIL PROTECTED]> wrote on 11 Jan 2002 20:44:44 -0500: > I think that's the point of trying to figure out a prefix for the > attributes -- so that attribute names in directories won't collide with > file names. So if you want a thumbnail for your directory foo, you just > do "cp icon.png foo/..thumbnail". (No special tools needed! Unifying > namespaces is great!) Why do we need to distinguish between attributes and files? We don't have to, or at least the file system doesn't have to (well, except for underlying indexability). The users can add a prefix or postfix to their names if they wish. But I wouldn't mind opening a file called: icon/thumbnail to get at the thumbnail's raw data. I'd also examine the "file" icon/thumbnail/content-type to get the MIME string that says what format the thumbnail is in (PNG, JPEG, etc). No need for prefixes, they just mean more typing at the keyboard! Particularly that hard to type "@" symbol :-). - Alex
Re: [reiserfs-list] Re: magic is useless & Determining File Types
David L. Parsley <[EMAIL PROTECTED]> wrote on Fri, 04 Jan 2002 19:23:11 -0500: > I'll agree that I initially thought the 'file as directory' idea had a > very high cool factor - but Linus, Al Viro, etc. convinced me otherwise. > This also makes me think you'll have a hard time getting the kernel > changed to let you open a file as a directory. Why did they reject the idea? It seems to work so well, having objects which have both contents (data like a file) and subobjects (like a directory). Is there an objection other than it isn't the traditional way of doing things? If the kernel people can't fit it in, it can be hacked around. Perhaps have each object appear twice in directory listings (once as a file, once as a directory, perhaps with a slightly different name). Or have an alternate API via ioctl codes until it gets accepted as being worthy of the kernel. - Alex
Re: [reiserfs-list] Re: magic is useless & Determining File Types
Andrew Clausen <[EMAIL PROTECTED]> wrote on Sat, 12 Jan 2002 09:25:18 +1100: > For package types, it's really both a Debian package and an ar > archive (yes?). Perhaps file(1) should know about such packages, > and call an extracter, and reinvoke itself? With the XML as a file system approach, the type of each subobject/file would also be visible. The type of the top level thing would be some sort of containerish type. If the user wants to know more, they can open it up (like a directory) and look inside. A GUI display of the top object's contents would have icons that reflect the types of the things inside the directory. > Using EAs also feels wrong. How do you embed files in XML? > Pipes? tar and friends need to know... If you open the file/object (what do you call it, a file which also has subfiles as well as content?) with the normal operation you get access to its data. If you open it with a directory type API, you see the things inside it (attributes and subobjects). If you open the magic attribute called XML, you get the file, attributes and sub-objects as an XML stream. You can also write to the XML attribute to recreate the attributes and subobjects (it replaces the current attributes/subobjects with the new ones when you close the magic XML attribute handle). Voilà! tar and pipes still work. - Alex
Re: [reiserfs-list] Attributes and Metadata about Metadata
toad <[EMAIL PROTECTED]> wrote on Sat, 12 Jan 2002 01:07:20 +:
>> The implementation detail is that the attribute/file/object type has
>> to be a special case, not a generic attribute. Perhaps a 32 bit integer
>> hidden in the underlying inodes. [...]
>
> A {sym,hard,COW}link?
What's a COW link? I'm familiar with copy-on-write, but that's a virtual
memory term. Is it like a MacOS alias?
- Alex
Re: [reiserfs-list] Re: magic is useless & Determining File Types
On Sat, Jan 12, 2002 at 03:32:00PM +0100, Xuan Baldauf wrote:
> Following the approach, you'd have to use those names:
>
> foo.jpeg/content
> foo.jpeg/content-type
> foo.jpeg/thumbnail.png/content
> foo.jpeg/thumbnail.png/content-type
>
> But this would not be compatible with the same approach above of naming
> metadata like this:
>
> foo.jpeg/content
> foo.jpeg/thumbnail.png
>
> Applications relying on finding the thumbnail using the name
> "foo.jpeg/thumbnail.png" would not find it anymore.
Why would they rely on using foo.jpeg/thumbnail.png, as opposed to
foo.jpeg/thumbnail.png/content?
BTW: why not foo/thumbnail/content? No point saying it's a jpeg twice
(in the filename, and the subdirectory)
> One could define that any metadata which has the chance to get metadata for
> itself has to be named in form of "${directory}/content", but you do not know
> in advance to which extend this applies to which metadata, so you would have
> to represent all data in that form (because all data is metadata in the sense
> of it's application, because all data states something about something),
> converting files into deep directory structures on the filesystem level. This
> would result in a tree-structured store of data (aka XML database). But this
> concept is too far, (and maybe too inefficient and complicated if mapped onto
> directories this way).
Why not support both options? If a file is a file, it's a file. (*grin*)
If a file is a directory with /content, then it's also a file ;)
> That is why you should not make a difference between the names of files and
> the names of files with attributes. If you do it, you do it like it is done in
> the programming language BASIC, where string variables are denoted as
> "variableName$" while integer variables are denoted as "variableName" (without
> the '$' mark). This is making the name of a file|variable dependent of it's
> type (in this case: real file or directory).
What does "name" mean in this context? How it's stored ondisk? How
it's addressed? (how it's addressed through syscalls? The GIMP?)
Andrew
Re: [reiserfs-list] Re: magic is useless & Determining File Types
Am Fre, 2002-01-11 um 18.59 schrieb Jens Benecke: > On Mon, Jan 07, 2002 at 12:46:22PM +0300, Hans Reiser wrote: > > > Let us get a bit more specific. You should echo "text/plain" > > > /etc/passwd/..mime-type > > >> I don't mind a prefix as long as it doesn't break anything else. If you > >> use '..' as a prefix that would break creating files that start with two > >> dots. I don't know why anyone would ever want to do that but it is > >> possible now, and it should stay possible, otherwise you risk endless > >> flame wars about people having to rewrite scripts or applications or > >> whatever. > > We know from experience with Clearcase and NetApp filers that reserving > > some of the namespace is not really so bad. Users survive it. > > Yes, the problems come when you migrate an existing setup to the > metadata-capable Reiser file system. > > One way around this might be an additional attribute that specifies whether > metadata exists. If it isn't set, then all chars are allowed in the file > name. If it is, then e.g. disallow "#" (or something more complex like > "#attr:") as part of a file name and treat strings behind it like a > metadata attribute. > > > However these are just crude workaround hacks that I don't really like > either. IMHO, we really need an additional layer between the file system > and the "desktop" (which includes bash & Co.) / end-user, which handles the > metadata operations. > > But we also need to convince just about every Unix programmer on the world > to use them, to become useful for all. Storing Content-Type in an EA and > forgetting about file extensions can become a major PITA if every second FS > (or transfer method, see FTP, Samba) you come across doesn't support EAs. > > It's even more than basch, ftp. samba and so on. Imagine the following: You tar several files, then gzip the tar file. Following, you tar the resulting tar.gz file with others in a cpio (or tar) to back it up or transfer it via rsh. As you see, the process of _storing_ content type must be recursive and supported in every program dealing with files (like netscape when storing). What about breaking compatibility of tar, cpio, gzip, bzip2, etc. with other operating systems?? I think, it's a nice idea, but difficult and perhaps unrealistic. just my 2cents Heinz-Josef Claes [EMAIL PROTECTED] > -- > mfg, Jens Benecke > http://www.jensbenecke.de/ - Persönliches > http://www.hitchhikers.de/ - Europas Mitfahrzentrale (car sharing agency) > > Politics is like a septic tank - all the big shits float to the top.
