6 ms·

No, just an explicitly-defined metadata field. Inference would be worse than filename extensions (which are awful). I think the original Mac OS fucked us all b

by veidr 3y ago

No, just an explicitly-defined metadata field. Inference would be worse than filename extensions (which are awful). I think the original Mac OS fucked us all by implementing this pretty much perfectly in the 1980s, but using their weird HFS "resource forks" to do it so that it not only couldn't be implemented on other platforms, but also lent credence to the "ugh fuck it lets just mangle the file name... and then hide it~!!! wooo000!~!" argument.. ¯\_(ಠ_ಠ)_/¯ UPDATE: My memory was faulty; the "what kind of file is this?" metadata was actually stored as per-file metadata, the "type" and "creator" fields in the HFS(+) filesystem.

pavlov 3y ago
Frustratingly NTFS has had proper metadata support for 30 years but FAT32 was a bag of rotten hacks, so Microsoft couldn’t fix this either even though their forward-looking OS had everything needed.
- veidr 3y ago
  I know. I'm getting close to 50 years old, and I have lots of *COMPLAINTS!!!* about how various tech (Atari 2600 ~ iPhone 15 Pro Max) worked out. But filesystems seem like the biggest species-level fuckup. Windows had their shit, Mac had HFS then "HFS+" until... tbh, quite breathtakingly, like five minutes ago, When they finally introduced APFS. But like... no checksumming, just Mötley Crüe data integrity, it's all good, iCloud backups FTW amirite!?! ZFS is good; I use it. But it didn't pan out, because a humanity-saving filesystem has to work on the systems humans actually use... (T_T)
  - babypuncher 3y ago
    Apple considered using ZFS but decided to build their own because Oracle. I do not blame them one bit.
    - veidr 3y ago
      I don't, either; that Oracle submarine pervert is the worst-remaining tech villain. Nevertheless, Apple built something objectively worse (T_T)
      - lostlogin 3y ago
        > worst-remaining tech villain. That crown would be a pretty tough one to hold, there are some good candidates.
    - chungy 3y ago
      They canceled those plans long before Oracle was even thinking of buying Sun. It's more a classic case of Apple's "not invented here"
      - babypuncher 3y ago
        APFS wasn't publicly unveiled until 2017, did it really spend more than 7 years in active development before then?
        chungy 3y ago
        Probably. File systems are hard to make sure to get just right. ZFS took just about 5 years to mature into a production release. From its inception in 2000 to production release in 2005. Oracle's btrfs (their attempt at competing with ZFS) began in 2008. Still isn't mature.
      - veidr 3y ago
        Well, even Sun was wedded to the (shit-the-bed) CDDL, but before Oracle there was the sense that a one-off deal might be made. Once Oracle bought Sun, it was like "Which is more important, your filesystem or your OS?" Which isn't a hard question with regards to any filesystem I've ever used except ZFS. Seems insane to use anything else for long-term storage, unless it has some kind of high corporate budget.
Someone 3y ago
> but using their weird HFS "resource forks" to do it That’s incorrect. File type and creator code always were stored where they belong: in the file system. Also, what’s weird about alternative file streams? > so that it not only couldn't be implemented on other platforms The main reason it “couldn’t” be implemented elsewhere is because of the dominance of FAT, which didn’t think it worthwhile.
- veidr 3y ago
  Oops, yeah, you are right. The type/creator codes were indeed FS-level properties. I'll update my comment.
paholg 3y ago
Why are filename extensions awful? I find it incredibly useful to tell what kind of file something is by just glancing at it. Or do you envision tools like `ls` and file browsers also showing metadata at all times?
- veidr 3y ago
  Yeah, I envision a future 1995 where not only does the GUI icon indicate what type of file it is, but the CLI tools also do (e.g. right before/after the "drwxr-xr-x@" or whatev)
  - paholg 3y ago
    When I type `ls`, I generally want to see file names and types, and nothing else. It would be really unfortunate to need a full `ls -l` to see file types. In fact, I always want to see file types alongside their names, so I really don't mind that the two are together.
    - js2 3y ago
      I think your imagination is failing you. The extension could be stored as a distinct field apart from the name. After all, we don't embed things like the file type (link, device, directory, etc) in the filename, nor things like the owner, group, ACL, access, creation time, etc. Separately, what `ls` displays with or without switches would be independent of how the extension is stored. Say the extension were a distinct field, `ls` could still display that as `{filename}.{extension}` by default. It's an accident of history that the extension is part of the filename.
      - eurleif 3y ago
        >Separately, what `ls` displays with or without switches would be independent of how the extension is stored. Say the extension were a distinct field, `ls` could still display that as `{filename}.{extension}` by default. But that would break piping the output of `ls` to other tools that expect a filename.
gsich 3y ago
>No, just an explicitly-defined metadata field. Inference would be worse than filename extensions (which are awful). Which are bad because those don't survive filesystem transmissions. A filename with extension will.
- veidr 3y ago
  Right, that was the original point that I was trying to make (but botched). The 80s Mac solved this near-perfectly, but then regressed to the current "just add a dot and some gibberish to the filename (and perhaps, or perhaps not, hide the gibberish and dot). Because when you copy a file to some other system (e.g. USB drive, or email attachment, etc), only the common properties survive. So having a filesystem with awesome capabilities that the others lack becomes worse, not better. (T_T)
- duped 3y ago
  > Which are bad because those don't survive filesystem transmissions. A filename with extension will. It won't actually because paths are not portable across file systems. The big reason is case sensitivity (and yes, some file extensions are case sensitive), but there's also issues with ASCII vs UTF-8 vs UTF-16 encoding. Meanwhile there are multiple standards for exchanging file metadata between file systems (SMB, NFS, FUSE, FTP, whatever). Most of these support arbitrary metadata on files.
  - gsich 3y ago
    A path is not a filename. The filename is part of it. Even with encoding issues, the chances that a filename survives are still much higher than filesystem metadata. For example: HTTP does not supply that metadata, so a file would lose it's "extension". Where would you store mimetype? Not in the file obviously.
    - duped 3y ago
      There's actually quite a bit of metadata that needs to be preserved when moving files between filesystems (file type, permissions, atime/ctime/mtime). Modern file systems support extended attributes for regular files and you can copy files between file systems with xattrs without too much trouble these days. In fact it's arguable that metadata is more reliable than file names, because that metadata is more standardized. > For example: HTTP does not supply that metadata, so a file would lose it's "extension". Where would you store mimetype? Not in the file obviously. Not sure what this point is. It's up to the HTTP serving application to determine what the mimetype of another file is however it needs to. A limited design could use file extensions, but a resilient design would just query the file system for unambiguous metadata. Like I said, there are multiple ways to do this. There's a lot of stuff that's not "in" the file. Like it's name.
alana314 3y ago
I remember Mac OS 8 not having file extensions and it was very difficult to change a file's type. I believe hexedit was involved. Extensions IMO are way more reliable.
- edbaskerville 3y ago
  ResEdit was the convenient app for that. Apple type/creator was a superior metadata system for sure, but the UI was opaque for non-technical users. Paired with the modern "open with..." settings, it would still be better than how file extensions are used today.

by veidr 3y ago

pavlov 3y ago

Frustratingly NTFS has had proper metadata support for 30 years but FAT32 was a bag of rotten hacks, so Microsoft couldn’t fix this either even though their forward-looking OS had everything needed.

veidr 3y ago
I know. I'm getting close to 50 years old, and I have lots of *COMPLAINTS!!!* about how various tech (Atari 2600 ~ iPhone 15 Pro Max) worked out. But filesystems seem like the biggest species-level fuckup. Windows had their shit, Mac had HFS then "HFS+" until... tbh, quite breathtakingly, like five minutes ago, When they finally introduced APFS. But like... no checksumming, just Mötley Crüe data integrity, it's all good, iCloud backups FTW amirite!?! ZFS is good; I use it. But it didn't pan out, because a humanity-saving filesystem has to work on the systems humans actually use... (T_T)
- babypuncher 3y ago
  Apple considered using ZFS but decided to build their own because Oracle. I do not blame them one bit.
  - veidr 3y ago
    I don't, either; that Oracle submarine pervert is the worst-remaining tech villain. Nevertheless, Apple built something objectively worse (T_T)
    - lostlogin 3y ago
      > worst-remaining tech villain. That crown would be a pretty tough one to hold, there are some good candidates.
  - chungy 3y ago
    They canceled those plans long before Oracle was even thinking of buying Sun. It's more a classic case of Apple's "not invented here"
    - babypuncher 3y ago
      APFS wasn't publicly unveiled until 2017, did it really spend more than 7 years in active development before then?
      - chungy 3y ago
        Probably. File systems are hard to make sure to get just right. ZFS took just about 5 years to mature into a production release. From its inception in 2000 to production release in 2005. Oracle's btrfs (their attempt at competing with ZFS) began in 2008. Still isn't mature.
    - veidr 3y ago
      Well, even Sun was wedded to the (shit-the-bed) CDDL, but before Oracle there was the sense that a one-off deal might be made. Once Oracle bought Sun, it was like "Which is more important, your filesystem or your OS?" Which isn't a hard question with regards to any filesystem I've ever used except ZFS. Seems insane to use anything else for long-term storage, unless it has some kind of high corporate budget.

Someone 3y ago

> but using their weird HFS "resource forks" to do it That’s incorrect. File type and creator code always were stored where they belong: in the file system. Also, what’s weird about alternative file streams? > so that it not only couldn't be implemented on other platforms The main reason it “couldn’t” be implemented elsewhere is because of the dominance of FAT, which didn’t think it worthwhile.

veidr 3y ago
Oops, yeah, you are right. The type/creator codes were indeed FS-level properties. I'll update my comment.

paholg 3y ago

Why are filename extensions awful? I find it incredibly useful to tell what kind of file something is by just glancing at it. Or do you envision tools like `ls` and file browsers also showing metadata at all times?

veidr 3y ago
Yeah, I envision a future 1995 where not only does the GUI icon indicate what type of file it is, but the CLI tools also do (e.g. right before/after the "drwxr-xr-x@" or whatev)
- paholg 3y ago
  When I type `ls`, I generally want to see file names and types, and nothing else. It would be really unfortunate to need a full `ls -l` to see file types. In fact, I always want to see file types alongside their names, so I really don't mind that the two are together.
  - js2 3y ago
    I think your imagination is failing you. The extension could be stored as a distinct field apart from the name. After all, we don't embed things like the file type (link, device, directory, etc) in the filename, nor things like the owner, group, ACL, access, creation time, etc. Separately, what `ls` displays with or without switches would be independent of how the extension is stored. Say the extension were a distinct field, `ls` could still display that as `{filename}.{extension}` by default. It's an accident of history that the extension is part of the filename.
    - eurleif 3y ago
      >Separately, what `ls` displays with or without switches would be independent of how the extension is stored. Say the extension were a distinct field, `ls` could still display that as `{filename}.{extension}` by default. But that would break piping the output of `ls` to other tools that expect a filename.

gsich 3y ago

>No, just an explicitly-defined metadata field. Inference would be worse than filename extensions (which are awful). Which are bad because those don't survive filesystem transmissions. A filename with extension will.

veidr 3y ago
Right, that was the original point that I was trying to make (but botched). The 80s Mac solved this near-perfectly, but then regressed to the current "just add a dot and some gibberish to the filename (and perhaps, or perhaps not, hide the gibberish and dot). Because when you copy a file to some other system (e.g. USB drive, or email attachment, etc), only the common properties survive. So having a filesystem with awesome capabilities that the others lack becomes worse, not better. (T_T)
duped 3y ago
> Which are bad because those don't survive filesystem transmissions. A filename with extension will. It won't actually because paths are not portable across file systems. The big reason is case sensitivity (and yes, some file extensions are case sensitive), but there's also issues with ASCII vs UTF-8 vs UTF-16 encoding. Meanwhile there are multiple standards for exchanging file metadata between file systems (SMB, NFS, FUSE, FTP, whatever). Most of these support arbitrary metadata on files.
- gsich 3y ago
  A path is not a filename. The filename is part of it. Even with encoding issues, the chances that a filename survives are still much higher than filesystem metadata. For example: HTTP does not supply that metadata, so a file would lose it's "extension". Where would you store mimetype? Not in the file obviously.
  - duped 3y ago
    There's actually quite a bit of metadata that needs to be preserved when moving files between filesystems (file type, permissions, atime/ctime/mtime). Modern file systems support extended attributes for regular files and you can copy files between file systems with xattrs without too much trouble these days. In fact it's arguable that metadata is more reliable than file names, because that metadata is more standardized. > For example: HTTP does not supply that metadata, so a file would lose it's "extension". Where would you store mimetype? Not in the file obviously. Not sure what this point is. It's up to the HTTP serving application to determine what the mimetype of another file is however it needs to. A limited design could use file extensions, but a resilient design would just query the file system for unambiguous metadata. Like I said, there are multiple ways to do this. There's a lot of stuff that's not "in" the file. Like it's name.

alana314 3y ago

I remember Mac OS 8 not having file extensions and it was very difficult to change a file's type. I believe hexedit was involved. Extensions IMO are way more reliable.

edbaskerville 3y ago
ResEdit was the convenient app for that. Apple type/creator was a superior metadata system for sure, but the UI was opaque for non-technical users. Paired with the modern "open with..." settings, it would still be better than how file extensions are used today.