On 2021-08-12 18:52, Grant Edwards wrote:
On 2021-08-12, Hope Rouselle <hrouse...@jevedi.com> wrote:

OS/2 had all kinds of amazing features (for its time). [...] Plus,
it had this fancy concept of "extended attributes"; on older
systems (like MS-DOS's "FAT" family), a file might be Read-Only,
Hidden, a System file, or needing to be Archived, and that was it -
but on HPFS, you could attach arbitrary data like "File type:
DeScribe Word Processor" or "Double click action: Run
CASMake.cmd". This allowed the GUI to store all kinds of
information *on the file itself* instead of needing hidden files
(or, in Windows' case, the registry) to track that kind of thing.

Yeah, that's kinda nice.  Isn't that a UNIX design?  A file is a
sequence of bytes?  Users decide what to put in them?

I think what he's talking about is allowing the user to attach
arbitrary _metadata_ to the file -- metadata that exists separately
and independently from the normal data that's just a "sequence of
bytes". IOW, something similar to the "resource fork" that MacOS used
to have. https://en.wikipedia.org/wiki/Resource_fork

So OS/2 was taking advantage of that to integrate it well with the
system.  Windows was doing the same, but integrating the system with
files in odd ways --- such as a registry record to inform the system
which programs open which files?  (That does sound more messy.)

Windows never had filesystems that supported metadata like OS/2 and
MacOS did. The registry was an ugly hack that attempted (very poorly)
to make up for that lack of metadata.

FYI, NTFS does support Alternate Data Streams.

UNIX's execve() is able to read the first line of an executable and
invoke its interpreter.  I guess OS/2 was doing precisely that in a
different way?

No, that's not at all the same thing. The #! line is part of the
normal file data. It's part of the 'sequence of bytes'. Metadata
maintained by Unix filesystems comprises a very limited and
pre-defined set of attributes present in the inode.

--
https://mail.python.org/mailman/listinfo/python-list

Reply via email to