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.
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] 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
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
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
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] 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
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
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
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] 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
