6

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
Improve this question
1
  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Chenmunka ♦
    Commented Mar 27, 2021 at 18:04

8 Answers 8

Reset to default
8

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).

Improve this answer
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
    Commented Mar 29, 2021 at 7:36
9

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 EAs. 4OS2 could store its descriptions in EA.

Improve this answer
8

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.

Improve this answer
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
    Commented Mar 29, 2021 at 0:02
7

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.

Improve this answer
6

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

Improve this answer
8
  • 1
    But isn't that an add on application on top of the file system?
    – Raffzahn
    Commented Mar 24, 2021 at 13:19
  • 2
    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
    Commented Mar 24, 2021 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
    Commented Mar 24, 2021 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
    Commented Mar 24, 2021 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
    Commented Mar 24, 2021 at 13:57
5

Does the Pick operating system fit in here? I have never seen it, but it is described as being based on associative arrays, which sounds much like a key-value store to me.

Improve this answer
2
  • Yes, but maybe you'd like to expand your answer with some details. Otherwise, it risks being 'link only', which is bad.
    – Mark Williams
    Commented Jun 29, 2021 at 8:47
  • I am sorry, but as I said, I have never seen or used it. There must be others on this site who have used it and would be able to describe it without resorting to conjecture.
    – idrougge
    Commented Jun 29, 2021 at 15:00
2

IBM System/23 (1981) had database functionality built in at ROM level. Where the distinction is made between the filesystem and the BASIC interpreter is uncertain though.

Improve this answer
2

MacOS and BeOS have already been mentioned here, but no has yet mentioned PalmOS. Development originally occurred on the Mac platform, and it inherited the Mac's technique of creating application files as a collection of resources, specified by type and ID number.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .