> Sorry for intruding into your list, but I need to report a good idea
> which just came to me and which you are competent to implement.
This was actually just mentioned on linux-fsdevel@vger
> I would like a future file system to allow something like this:
>
> $ chft latex_sjis myfile.tex
> $ chft -R latex2e_class $TEXMF/tex/latex/base
>
> The keywords latex_sjis, latex2e_class etc should be managed in a
> similar way as owners and groups are managed now. Moreover they
> should point to a user-editable database which should again support
> pointing to other data of any desired complexity (even whole
> directories containing meta-information), with a query routine for
> these data in the system library.
First concern: this kind of 'type management' will be completely
site-dependant, so applications wishing to use them will rely on the
ability to add to the system database (or have it modified by the
administrator). Also, you will be unable to have these attributes saved
and restored across systems in their "native" form; they must be
translated to some canonical representation for transport, then re-mapped
onto the target system's local name<->number system. Consistent,
site-independent magic numbers seem cleaner to me; perhaps it would be
more reasonable to use the appropriate magic number (or a
truncated/expanded version of it) for the 'file type' field?
> At first sight this may look like a proposal to bloat the Unix file
> system. But the filetype info really belongs into each directory
> entry, because
(Some others have mentioned this) - you mean the inode, since that's what
represents the actual object/content. The directory entry is just a
pointer to it from a human-readable namespace.
> (2) The info cannot be added onto the file, because existing
> file types (such as images) would be corrupted by such addition
...Most sane modern file types include magic numbers (including many of
the image formats that would be corrupted)...
> (3) The info cannot be given by writing it into a separate file,
> because file utilities (such as mv, cp, ln) know nothing about
> such file grouping and will always tear the groups apart.
Big problem here: traditional file utilities (cp, tar, gzip, ...) are also
not aware of this "file type" extension; the argument against doing it
with separate "attribute files" also holds against doing it with
non-standard file attributes.
> (4) An additional integer isn't really bloat
Real estate in the ext2 inode isn't exactly easy to come by (especially if
you exclude the bytes that are already in use by not-yet-mainstreamed
features...)
Adam
-- You crucify all honesty \\Adam D. Bradley artdodge@cs.bu.edu No signs you see do you believe \\Boston University Computer Science And all your words just twist and turn\\ Grad Student and Linux Hacker Reviving just to crash and burn \\ <>< ---------> Why can't you listen as love screams everywhere? <--------
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/