Re: file types

At 11:01p -0700 10/24/96, David Perrell wrote:
>Scott E. Preece wrote:
>> I guess I don't understand your argument - TIFF has an embedded file
>> type code (the same kind of thing I was talking about).
>
>Either 49492Ah or 4D4D2Ah, depending on byte order of multi-byte
>values. The 2Ah is the never-changing version number. (Are we still at
>Rev 5.0, circa 1988?)

6.0 came out sometime this past year, didn't it?


>> I'm not sure you're better off in TIFF for not having a simple
>> way to judge compatibility from the outside (without a lot of
>> processing).
>
>Designed for intersystem portability. Don't let those lazy programmers
>give up too easily.

It's not so much that -- you actually stated the problem below, about
directory listings...


>All fine and dandy, except that to avoid the overhead of opening and
>reading a file to find out the type, the type must be part of the file
>system, not embedded in the file data. I know of no possible mechanism
>for this in the FAT system besides the extension and a single attribute
>byte. I believe the same is true of NTFS, though here you've got long
>filenames and support for UNICODE characters.

So must the future of file typing be limited by FAT which was not very
forward-thinking (they should've reserved more space for future use)?
As you said, death to FAT? ;)

Actually, there are programs which claim to assign long filenames to
8.3 files under DOS/Windows. If FAT can be extended that way, can't it
be extended for file typing as well? I know it'd be a kludge, but that's
because FAT is too bare-bones.

>Can you imaging having to open tens of thousands of files
>to construct a readable folder/directory listing?

This is why file systems need to be improved -- file metadata should not
be part of the filename. It's too limiting! There is too much information
to fit into a filename. Date of modification, date of creation, date of
last access (Unix), file type, file flags, etc. Filenames are fragile
things, too easily changed by a user or a gateway. Metadata should travel
with a file (see MIME), and be handled by local filesystems. The MacOS is
modular, and can be fitted with "foreign" filesystems. In fact, there is
an Apple technote which warns that the colon is not guaranteed to be the
only path separator! I can rest secure that if more file metadata is needed
in the future, Apple can supply a post-HFS file system capable of tracking
additional metadata (perhaps Unix's access date, for example). Computer
technology should evolve! If the future of computing is to be dictated by
FAT, then computing will never leave the dark ages. Evolve! Evolve!

__________________________________________________________________________
    Walter Ian Kaye <boo@best.com>     Programmer - Excel, AppleScript,
          Mountain View, CA                         ProTERM, FoxPro, HTML
 http://www.natural-innovations.com/     Musician - Guitarist, Songwriter

Received on Friday, 25 October 1996 06:25:29 UTC