Re: [reiserfs-list] Re: magic is useless Determining File Types
Xuan Baldauf [EMAIL PROTECTED] wrote on Mon, 14 Jan 2002 03:56:00 +0100: No. Once you modify your applications to use the access form foo.jpeg/content, files without attributes (files which have to be accessed using the old access form foo.jpeg) won't be accessible anymore. The temporary workaround during the transition period is to have two mount points for the file system. One gives you the new view of the data (attributes and all), while the other one just gives you the old unattributed one (suitable for tar'ing up C source code for distribution). Actually, if kernel stat() isElement O(1) and readdir() isElement O(n) [...] As part of indexing, I'm hoping for sorted directories (or with Reiser V4, that's a custom directory type plus plug-in). Then readdir() is O(log n) to find the place it left off from reading before, and so is stat() to find the file it is stat'ing. That reminds me about back links. Currently a file just has the count of the number of links to it, but doesn't know what they are (and people shouldn't be using this as the count of the number of items in a directory!). I'm experimenting with including a list of backlinks in my RAM disk file system for BeOS, and it comes in useful for an improved alias/hard link. Probably would also be useful for reconstructing directories (not a concern with RAM disks :-). - Alex
Re: [reiserfs-list] Re: magic is useless Determining File Types
Hubert Chan wrote: The .. just means something special to the OS, It doesn't mean something special to the OS, you guys are missing my intention, it is a style convention, not more. Hans
Re: [reiserfs-list] Re: magic is useless Determining File Types
Alexander G. M. Smith wrote: 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 Viro rejects (it isn't his father's Unix is I think the reason), Linus thinks it is fine and proved that VFS could handle files being directories. Hans
Re: [reiserfs-list] Re: magic is useless Determining File Types
Andrew Clausen wrote: 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. That's the point. :-) There shall be the possibility of adding attributes to files and there shall be files being accessible by using the same name as used before, so, for complying to both requirements, there must be a possibility of adding attributes to files without requiring to rename them. 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. I agree with you that this could be done in userspace, but (1) It has to be done below the application level (e.g. glibc), not higher (like GNOME), because all the tools (tar, cp, etc.) _must_ still be able to open foo.jpeg if it has morphed into foo.jpeg/content using the same name. (2) It will slow down disk accesses, because for every attributed file, there will be two calls needed to access the file. But this can be optimized by kernel support and changing glibc appropriately at a later stage of distribution of attributes. (3) What do you do with attributes of directories? There are conventions for UNIX-style filesystems that the number of subdirectories within a directory is the link count of that directory - 2. This convention might be changed if attributes of directories are implemented as entries of that directories. A glibc-implementation could reimplement stat to return the conventional link count at the cost of a subdirectory scan and the associated performance penalty, though. (4) There will be some glitches, like the atomic rename(2), which by definition automatically unlinks the destination file if it exists in one step. If implemented in userspace, there won't be atomic rename-over-attributed-files. After all, implementing within glibc sounds feasible for me and the only semantic drawback is the missing atomicity of rename(). This is not the fault of glibc per se, but the missing transaction API between kernel and userspace. Even the filesystem namespace occupied for attributes can be hidden by a glibc implementation which escapes names used by applications which would denote an attribute if read by glibc again. This implementation would be inefficient but portable. Note that I still see this implementation only as a transitional implementation until native kernel and filesystem support is available. 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
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] 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] Re: magic is useless Determining File Types
Chris Dukes [EMAIL PROTECTED] wrote on Mon, 7 Jan 2002 16:34:28 +: A wise person once said those who do not know Unix are doomed to reinvent it, poorly. In the case of structured files, it would appear that those that do not know OS/400 are doomed to reinvent it, poorly. Good point. I usually find that talking about something I think is new flushes out a comment from someone that it's already been done. But at least now I know enough to pause and hunt up info on OS/400 and Mungi. Thanks. I still question putting resource fork capabilities into a single existing filesystem at this time. [...] Yup. As we discovered in another series of messages here, it could easily be built on top of a simple file system (though preferably with change notification). That's probably the way to go. - Alex
[reiserfs-list] Re: Magic is useless!
Raphael Bosshard [EMAIL PROTECTED] forwarded a message on Mon, 07 Jan 2002 20:09:17 +0100, it was originally from Daniel Veillard [EMAIL PROTECTED] on Mon, 7 Jan 2002 12:24:14 -0500, and addressed to the Gnome 2.0 list: Yep, IMHO Mime-Type are slowing falling into obsolescence due to composition and the fact that it's such a f...g pain to update that registry that some new format tend to not even bother. I wonder if he's talking about the W3C official registry or some software registry. It isn't that hard to add new MIME types to the BeOS's system (usually under the vendor specific groups). But yes, some objects are documents that contain many other things. Perhaps call them text/xml/document? Then your favorite XML composite viewer could open them up and load appropriate viewers for subobjects which do have a more specific MIME type. The goal of the Mime-Type was to associate processing tool with resources. Unfortuantely it's a too limited view to cope with most of the complex formats. A better approach is a list/hierarchy of strings and not a single one, the list of namespaces name of a XML document, the list of mimetypes of a zip. To take the example of a ZIP format it could be: (zip (image/gif, xml/docbook, image/gif)) to use a LISP like syntax. For a compound compressed XML document (gzip (application/xml (http://www.w3.org/2001/svg http://www.w3.org/))) I'm pretty sure you can find examples even outside of the XML world. don't limit yourself to known-to-getting-obsolete mechanism when defining new interfaces. Heh. Looks like a directory listing of the object system hierarchy, but with the types rather than the object names. But would that be useful for any real world purpose? If you have indexing working, you can find sub-objects of specified types (and other classifications) even if they are inside bigger objects. No need for overly descriptive MIME composites, unless you want them, and then they'd be easy to do. - Alex
Re: [reiserfs-list] Re: magic is useless Determining File Types
Chris Dukes [EMAIL PROTECTED] wrote on Sun, 6 Jan 2002 01:40:51 +: 2) I see a lack of consensus about what sort of metadata should be grafted onto files, yet I already see questionable arbitrary limits appearing. Perhaps some of the advocates could make references to userspace rich file format APIs that provide the functionality you seek. Since the Be site is out of business, here's a link to another web page with the documentation on using attributes: http://bang.dhs.org/be/bebook/The%20Storage%20Kit/AttrFuncs.html There are other related pages for indices, and more importantly, queries (note they have convenience functions for building the expression which selects files, but under the hood it boils down to a string in the query language, which the file system parses): http://bang.dhs.org/be/bebook/The%20Storage%20Kit/Query.html - Alex
Re: [reiserfs-list] Re: magic is useless Determining File Types
Ross Vandegrift wrote: echo requires good stereo to sound good filename/..comments Then what about the following: $ ls -aF ./ ../ somename somename_dir/ $ cp ~/file somename when I meant $ cp ~/file somename_dir/ but missed the typo? Does cp need someway to know that file isn't extended attributes? Does it just use the '..' at the beginning? Give someone a bulldozer, and they can make more mistakes with it than with a shovel. On the other hand, if I wanted to apply extended attributes to a large number of files something like: $ cp ~/..ea_set */ in a directory would be a very natural thing to attempt. But can I tell ReiserFS/VFS that ~/..ea_set doesn't actually apply to my home directory, but rather it's just a storage place for some eas I want to put elsewhere? Yes, call them ~/ea_set without the .., and user land will not think they are attributes. Obviously these issues won't come up when human error isn't involved (I could obviously call the file in ~ 'ea_set' and rename it '..ea_set' when moving it into place). But it will be frustrating for current users to learn counterintuitive limitation so GUI users can be happy. Ross Vandegrift [EMAIL PROTECTED]
Re: [reiserfs-list] Re: magic is useless Determining File Types
Miguel de Icaza wrote: Let us get a bit more specific. You should echo text/plain /etc/passwd/..mime-type Note the prepending with '..', as this allows distinguishing directory meta-data from files by use of a style convention. Folks, if you don't like .. as a prefix for meta-data, now is a good time to suggest something better. Do you need the prefix? I would love to not have the prefix (but I dont really care, what matters is to have the functionality). Why do you not want the prefix? I am easily swayed by an argument against it if I hear one. (The prefix is an optional style convention for metadata about an object, not a requirement imposed by the FS. In other words, no we don't need the prefix, but we don't know why not to use it.) Hans
Re: [reiserfs-list] Re: magic is useless Determining File Types
Hans Reiser [EMAIL PROTECTED] wrote on Sat, 05 Jan 2002 02:52:56 +0300: I think that with reiser4, we just need to settle on a style convention (what is it called, ..content-type or ..mime-type or ..type or.?) Do we need to write a plugin for it? I think maybe not, I am not sure the filesystem ever does anything with the attribute, it is purely a user space affecting attribute. If you're doing indexing, then the file system does need to update its index directories with the current value of the attribute and the pointer to the file. But it would need to do that with all attributes that are being indexed. - Alex
Re: [reiserfs-list] Re: magic is useless Determining File Types
On Sun, Jan 06, 2002 at 12:39:05AM +0100, Jens Benecke wrote: I don't know if there are any (printable) characters that are NOT allowed in Unix file names yet but if there are, use those. They are '/' and '\0' Anyhoo the following needs to be pointed out. 1) I question the need for metadata capabilities to end up in ReiserFS (or ext2, or ext3) at this time. 2) I see a lack of consensus about what sort of metadata should be grafted onto files, yet I already see questionable arbitrary limits appearing. Perhaps some of the advocates could make references to userspace rich file format APIs that provide the functionality you seek. [1] 3) Given some APIs, perhaps a common API wrapper that the average coder could be encouraged to use correctly and manages to work on common desktop and server operating systems. 4) Given an API, create a usermode filesystem that makes the extensions transparent[2] to programs that don't use the API and work out the interface issues. 5) Once the usermode filesystem has reached a point where it doesn't give Al Viro nightmares, start moving the new functionality to the common VFS layer. 6) Once the extensions are in the VFS layer, consider tweaking existing filesystems to handle the extensions more efficiently. 7) All of this appears to be an attempt to graft the behavior of a single level store operating system (Like OS/400 or Mungi) onto the Unix model. I wonder if it would not be more efficient to adapt a single level store system to desktop use, now that they ship with POSIX subsystems. [1] I would like to thank the person that mentioned XML although that's a bit later than the API :-). [2] Then again, I would rather see rich file that can be manipulated by command line file and directory manipulation tools flagged as a filetype other than file or directory, so much for transparent. -- Chris Dukes Bert is apparently VIL, whereas Oscar is just a sysadmin^Wgrouch. -- gorski
