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

Re: Extended attributes

On Sat, 01 Jan 2000 10:41:17 +0100, the world broke into rejoicing as
Dirk Ritter <dirk@gnumatic.de>  said:
> Hello Christopher Browne!
>  On Fri, 31 December 1999 at 22:07:49, you wrote:
>  [*.c associations]
>  > ... And with a print utility ...
> And with an indentation tool and a source code analyzer and a spill
> checker and a documentation generation system and ... oh dear -
> where is bash - give my shell back to me and get me outta here! ;-)


>  > I'm not sure that the EA necessarily needs to go with the file in this
>  > case.  I suspect that putting the control information in something
>  > like unto ~/.mailcap
> Why record type information at all? 

I didn't say "type information."

> I got curious and proved it -
> even 'file' as it exists today spits out type information for
> roughly 100 files within two seconds or less. Of course - I have
> a reasonably fast SCSI disk and 800 Bogomips, but when I ran it
> a second time it was just about as fast as a directory listing.
> Are you guys sure that information which can be gathered as fast
> is really worth recording? I have considerable doubts about it.
> Besides - 'file' already has great knowledge about file types, so
> why try reinventing the wheel? Why even think about the good old
> stone axe if you can do it with power tools?
> (Of course plain text vs. english text vs. not very english text is
>  a bit spotty but this can be forgiven since 'file' even identifies
>  a GNU/Linux Software Map as such (ever read about LSM entries?).) ;-)

I fully agree that using "file" is a tremendous idea.  By the way,
if it's not fast enough as-is, reading through a text file, it would
make sense to build a version that hashes that into a DBM table, thus
reducing time and disk accesses to pretty much O(1).

[Parallel this with using a DBM'ed /etc/passwd file; many UNIXes come
with utilities that can compile /etc/passwd into /etc/passwd.dbm, so
that if the DBM file is there, and is newer that /etc/passwd, you can
get *real* fast access.  Or look at the file I run "file" on, namely
/etc/aliases.db, which is another example of this...]

But this digresses from the *true* issue.

The *true* issue is not so much determining the file type as it is
determining what to do *as a result of the file type.*

We can use /etc/magic (or /etc/magic.dbm) to determine that the file
is of some type.  For instance:

# file /etc/aliases.db
/etc/aliases.db: Berkeley DB 2.X Hash/Little Endian (Version 5, Logical sequence number: file - 0, offset - 0, Bucket Size 4096, Overflow Point 2, Last Freed 0, Max Bucket 3, High Mask 0x3, Low Mask 0x1, Fill Factor 0, Number of Keys 0)

What that *doesn't* tell us is the *control* information of what program
to use to *process* it.

*THAT* is the thorny issue under discussion.

/etc/mailcap contains correspondences between MIME types and programs to
be used to process those types; *that* is what is being discussed.
"...Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and
the Ugly)."  -- Matt Welsh
cbbrowne@hex.net - <http://www.hex.net/~cbbrowne/lsf.html>

Reply to: