[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Extended attributes

>>>>> "Christopher" == Christopher Browne <cbbrowne@hex.net> writes:
    Christopher> Three associations:
    Christopher> 1. [data file] --> [file type]
    Christopher> 2. [file type] --> [default application list]
    Christopher> 3. [data file, file type] --> [override application
    Christopher> list]

Some comments:

1. would be stored in EAs or whatever. I do not think storing this
information under the users home directory is a good idea, as that
would limit use between users and different computers. This information,
if implemented correctly should not depend on any single user or

2. would be stored in /etc/mailcap or ~/etc/mailcap

3. I am puzzled as to what you mean exactly. My guess is
that maybe you mean something like:

/full/path/to/file image/jpeg --> gimp

This information could be stored in a users home directory.

Is this correct? Then, I guess you could also have

/full/path/to/* image/jpeg --> gimp

which would be good, as only image/jpeg files are affected. However,
if you wanted all images, then maybe

/full/path/to/* image/* --> gimp

So, if I used:

* image/jpeg --> gimp

this would do the same thing as mailcap.

(perhaps regular expressions would be better).

If this *is* what you meant, it is an interesting idea, but not sure
if it would have any practical benefit. Perhaps if you get a CDROM
which had incorrect MIME types, or something, then it would be useful.
In this case, you would need some way to identify the CDROM. Or maybe
you have different projects, and different programs suit the needs of
each project better.

Another note:

This could be done on the fly with file, or something similar. This is
why I think it would be a good idea to abstract this functionality
with a library. Different people will have different opinions, and I
think we have to cater for that. However, IMHO, I consider file to be
a hacked solution, that just happens to work most of the time. If
there was some standard on where/what magic bytes were kept, then I
would reconsider, but so far every file format has a different
standard, and there is no reason file formats wont conflict.

For instance, looking through /usr/share/misc/magic, I can already see
a file format that conflicts (and is disabled by default) - a file
that starts of with the string "HAWAII". Perhaps this is a bad
example, then what about the comment that DL aminimation formats
conflict with mips magic. Actually "conflicts" is mentioned a number
of times in the magic file.

Even worse, is the magic I see for Microsoft documents. I string of
"Microsoft Word 6.0 Document" at location 2080 automatically makes the
file a Microsoft Word document, for instance (according to the magic
file in potato).  What if I were to have a a text/binary file that
just happens to have the same string in the same place?

Brian May <bam@debian.org>

Reply to: