5

Attribute–value pair is quite common in programming languages, databases, URL query-strings, and Email/HTTP headers, which could also be used to organize, classify and version files.

Extended file attributes are available in HPFS of OS2, ext2 of Linux, and WinFS of Vista, etc. However, no significant usage was seen in file systems, let alone taking the place of hierarchical directory structure. Why?

Links:

  1. Where does the hierarchical directory structure originate from?
  2. Filesystems with versioning
  3. Unix Haters Handbook - guaranteeing synchronous, atomic operations
  4. https://stackoverflow.com/questions/3263036/file-system-that-uses-tags-rather-than-folders
  5. https://en.wikipedia.org/wiki/Attribute%E2%80%93value_pair
  6. https://en.wikipedia.org/wiki/Extended_file_attributes
1
7

I'll admit to not quite understanding their jargon, but it looks like IBM's AS/400 (1988) and to a certain extent, System/38 before it (1978) relied on object or database-style single-level storage rather than hierarchical files.

1
  • Good catch, I think you're right about System/38. It was very unique, not least because it was a successful commercial product, not a university research toy. – davidbak Mar 29 at 0:02
6

The BeOS used extended attributes heavily.

In OS/2, rexx scripts are tokenised into extended attributes, and all sorts of things like icons and whatnot used them. There were a decent arrangement of tools to access and edit the ea's. 4os2 could store its descriptions in ea.

5

The Sinclair QL's file system has a 64-byte "File header" providing metadata for the file. Among system-owned fields like modified/access dates, file length, type and name, it also holds 8 bytes of so-called "type-dependent data" that can be used by specific file types for their own metadata.

Due to the structure of QDOS I/O, that header is also (optionally) provided when files are transported over non-block media like network or serial streams.

This concept shares the same problem with a lot of early metadata technologies: When transferred over to a non-metadata-aware block file system (like a FAT disk format, for example) the metadata is lost (obviously with file type-dependant consequences).

As to the "why?" (or rather, "why not?") I think that's the exact reason.

5

It would be remiss to neglect the original Mac HFS with its core support of the Resource Fork.

A normal Macintosh file had two forks: the data fork, and the resource fork. The resource fork was a key/value store, with the values typically being large binary blobs (most notably icons, code, sounds, etc.). The data fork was where typical "read" and "write" operations would work.

Applications, in fact, stored pretty much "everything" in the resource fork, with little to nothing in the data fork (which is the traditional view of the file).

1
  • 2
    You should mention that MFS introduced resource forks in 1984, before HFS in 1985. And also that "ordinary" metadata in those FS is still static, and not key-value. – dirkt Mar 29 at 7:36
4

AmigaOS, first released in 1985, made extensive use of key/value attributes that could be defined by the user in a GUI and recognized by any tool. (e.g. an application/program).

This was done using a metadata system implemented through "Tool types" that were embedded within the .info file. Every Tool or Project (e.g. a document) had an icon and other metadata in its .info file. The Tool types were a small database of key/value attributes. When an Amiga application is launched from Workbench, those key/value pairs are available to the app at startup in a manner similar to command-line arguments.

It is important to recognize this is pure metadata defined by the user and not dictated by the application. And this metadata is exposed through a built-in GUI that is part of the standard desktop environment. You don't require special tools that decode binary "resource fork" files, or similar. The user could utilize this metadata for their own purposes, including tagging related files independently of folder hierarchies. Also noteworthy is that the Amiga's filesystem metadata implementation was managed by Workbench (the standard GUI "shell") as a layer above the filesystem proper.

enter image description here

8
  • But isn't that an add on application on top of the file system? – Raffzahn Mar 24 at 13:19
  • 1
    Didn't doubt that it was shipped with the OS, but it's not part of the file system. It is an application storing whatever it needs to do its job in regular files. They are configuration files, indistinguishable from any other from a FS PoV, not mechanic provided by the file system to hold meta data, like asked for. – Raffzahn Mar 24 at 13:29
  • 1
    @Raffzahn I get your technical point and you are correct that the metadata for a file is stored as a separate, but associated, first-class file. The reason I would still offer this as a partial answer with historical significance is becasue i interpret the question as being about the OS opening up file metadata to the user directly, to enable the use-cases described in the question. – Brian H Mar 24 at 13:41
  • 4
    Also, it's supported by the AmigaOS API. So, even from a programmer perspective, its an integrated feature and not an add-on. Unlike, say a Windows INI file, the OS is explicitly binding the metadata to its sibling file, rather than leaving that as a user or programmer exercise. – Brian H Mar 24 at 13:47
  • 1
    To me the question clearly asks (already in the title) for file system support. If configuration files count, then every file system since tape times would qualify - as soon as some application is there to read them and act accordingly. About Windows: there were not only 'private' INI files, but also PIF, managed by the shell - they were even cross-compatible with other windowing systems like DESQview (would Amiga do that?). Last but not least having an API doesn't make it part of an FS - there were DDL for INI handling. And isn't using librariesthe core idea of Amiga OS (as well as Windows) ? – Raffzahn Mar 24 at 13:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.