Hacker News Reader

Comment by veidr | Hacker News Reader

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.

View on HN

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?

That reminds me of relying on static type inference so much that the code is hard to follow in Github and you need to pull it into your IDE just so you can keep track of the types as you read it.

While a filename extension could probably be superseded by file metadata, it's also nice when you can read the intention right in the name without additional tooling.

Especially when you consider a hypothetical world without filename extensions thus every UI shows the filetype next to the filename thus "readme.md" in our world is just "readme:md" in their world, and it's not obvious what was gained nor lost.

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)

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.

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.

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

You shouldn't parse the output of `ls`:

https://mywiki.wooledge.org/ParsingLs

https://www.shellcheck.net/wiki/SC2010

It's brittle and the output is designed for humans, not machine parsing.

Use a glob or find.

In a world where extensions were their own distinct metadata, whether or not to show them would be a switch to `ls` (whose output you shouldn't be parsing) and how to retrieve that metadata from a filename w/o parsing `ls` output would be something like:

   ext=$(stat --format="%E" -- "$filename")

You'd also have a switch to `find` to select files by extension instead of having to pattern match their names.

This is a reasonable argument against parsing the output of `ls` within a shell script that you're going to save and reuse in arbitrary directories. It's not a reasonable argument against ever parsing the output of `ls`. If it were, it would also be an argument against humans reading the output of `ls`. The example in your first link makes its point by showing output from `ls` that the human reader can't parse. That doesn't demonstrate that the output of `ls` is "designed for humans, not machine parsing"; it demonstrates that in the general case, its output cannot be parsed by either humans or machines.

My rule is that it's ok to use `ls` only in a directory where you know the filenames aren't weird. That rule is the same regardless of whether a human or a computer will be parsing its output. In general, reusable shell scripts shouldn't make assumptions about their environment, so they shouldn't use `ls`; but piping `ls` to another command in a one-off manner at an interactive shell is fine if you know the filenames in the directory aren't weird, just like it would be fine to use `ls` at the same interactive shell and simply read its output yourself.

You can have tty output be different from pipe output

If they weren't together, you would just define an alias that works exactly how you want it.

Instead they went with executables all having unique icons, and icons for non-executable files changing depending on which executable was last granted permission to open them.

I've learned in code not to rely on arbitrary user generated strings to designate the document type as they can be incorrect or non-existent. They're fine as a possibly unreliable indication to users, though.

Exactly, filename extensions are like personal pronouns for files.

Not awful, but misleading. You can fake name any file extension anything ala quake approach to data files being archives.

They are not. Everything else is insanity.

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.

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)

Apple considered using ZFS but decided to build their own because Oracle.

I do not blame them one bit.

I don't, either; that Oracle submarine pervert is the worst-remaining tech villain.

Nevertheless, Apple built something objectively worse (T_T)

> worst-remaining tech villain.

That crown would be a pretty tough one to hold, there are some good candidates.

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"

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.

APFS wasn't publicly unveiled until 2017, did it really spend more than 7 years in active development before then?

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.

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

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

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

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)

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

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.

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.

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

Those are not hard requirements. It's nice to have, but in doubt it will just be what the destination filesystems think those values should be.

>There's a lot of stuff that's not "in" the file. Like it's name.

Correct. And everything not in the file is in danger of being lost. The filename (with extension) is the minimal viable data that has a chance to survive. The extension even more so than the basename.

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.

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.

Reply on news.ycombinator.com