29 Aug
2006
29 Aug
'06
2:07 p.m.
About ten years ago I got into a similar discussion
with some friends
about this, and even designed a file system that not only could
support user added metadata, but even the concept of a "name" was
fluid (you could actually use an audio clip as the "name", or a
graphic). It would also allow one to "cd" into a jpeg (for instance)
and see all the segments that make up a JPEG file [...]
This reminds me of a project I did for Universitetet i Troms? (a
university in Norway). One of the things it did was present a
directory view of a file - given a plain file foo/bar, you could access
things like foo/bar/id and foo/bar/parent and suchlike. A slightly
different slant on that and you've got the sort of thing you're talking
about.
But how would I copy a file "named" <FX
of screetching tires> to some
other system, like Unix?
"With difficulty"? :-)
Actually, the notion of such an object rapidly leads me into some
curious speculation on user interfaces - I'm having trouble coming up
with a UI under which it's practical to use such a name.
[A]t the time [Unix started], you really only had
three different
types of files (excluding the special device files)---executables,
object code and text files.
[Whee, something approaching real classic content!]
Actually, executables and object files were really the same type; the
only difference was that executables (a) normally had their execute
bits set and (b) didn't have any undefined external references left.
(I'm not sure, but it's also possible that the entry point in the a.out
header was another point of difference. It's been too long since I
worked with a.out files.)
This changed, eventually; first we got different magic numbers to
support demand-paged executables and suchlike, then after a while when
everyone was experimenting with different object/executable file
formats, ELF seems to have largely won out....
It's harder if this metainformation is stored as
something else (like
the 4 byte type field on the Macintosh---not sure what it's called
exactly).
File type and file creator - there are actually two of them. By an
interesting coincidence, I was just today talking with a friend of mine
who's a serious Machead, and he tells me that, while modern Mac OSes
support file type and creator fields, they are for compatability; they
are not used for much these days. (The notion of forks is another one
that's on its way out; practically nothing needs anything other than
the data fork - and, interestingly enough, since (Mac) OS 9, a more or
less unlimited set of forks has been supported, not just a data fork
and a resource fork.)
He tells me that if creator information is present, it is used to find
the right app for a file, whereas if not, it defaults based on the
extension - and the UI has ways to override this, either one-time
("Open With") or by bashing the creator field on the file to make it
sticky.
So, on a Mac you have the file "vacation"
but the type is (as an
example) 0x4A504547. It's meaningless on Unix, and it's a value that
won't fit into the MS-DOS extension field.
Another important difference here is that on Unix, the file "type"
field is part of the name, and thus (eg) vacation.jpg and vacation.txt
can exist in the same directory on Unix, whereas it is not possible to
have "vacation" of type 0x4a504547 and "vacation" of type 0x54455854
in
the same folder on a Mac. I'm not sure whether this is an argument
either way, but it *is* a difference.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B