You, as a data point (and I, and I imagine many people on HN), are strong evidence of the rule "sufficiently motivated and clever end users will always find a way to do what they want, regardless of the interface".

But that isn't really saying anything about if the interface sucks, or could be improved, just that you're motivated and clever enough to find a good and scalable solution for what you want to do given the limitations of the interface.

I do the same. This is the only way to organize things, by date.

I do the same with documents. I don't even want to think about categories, ontologies are always wrong. But today is 2022-02-24, no two ways about it. It's automatic, there's no need to think or decide anything, so it's not a big deal, you just do it. You can't make a mistake.

The thought of needing to properly tag every document I file is enough to make that a task I want to postpone. So it wont get done. That's a worse filesystem right there, because it doesn't exist.

I agree that sorting by date/time is 90% correct default view of the data. Most file managers have this wrong.

It should be especially easy to have a full sub-tree view sorted by date, but it typically isn't.

None of the files in the 1997 tree have a file date anywhere near that old, the drive they are on wasn't created until decades later.

For me, there is only one durable, universally supported tag for those files, which is the folder structure. Due to the way cameras number photos, for any given photo file name, there are likely 5-10 other different photos with the same name.

You might be tempted to then call for a standard tag that would be supported, but what about files relating to things of unknown dates? Fossils, antiques, draft x of the Declaration of Independence, or of things planned in the future, with dates still in flux?

Having one canonical path and filename for a given collection of bits is a really effective tool, that I doubt will be surpassed any time soon.

However, the next best thing, in my humble opinion, is to use a cryptographic hash of the file in question, as Git does internally. You could map a filesystem interface to a data store based on Git, as long as you don't expect high speed writes to work with performance. (because new checksums require computing across the entire file, even if only 1 bit changes)

But look at the path components: they're not organizing things just by date. The files are first organized by purpose (long-term storage), then by origin, and only then by date.

So they've already made the decision to commit the files to long-term storage, and to keep the original photos separate from subsequent edits, and to keep them separate from other image sources (e.g. downloads). That "tagging" required very little effort because they could just navigate to the existing tag in the filesystem, and put the new files there.

> This is the only way to organize things, by date.

I am terrible at dates - if I had to find photos by date I'd never find them. For anything older than a month that isn't on a known anniversary like a birthday, 90% of the time I find the photos using the map view in iCloud Photo Library. If I was limited to a filesystem view, my photo library would be far less useful.

What you've done here (and it's no bad thing given filesystems!) is define dates as an ad hoc index over a primary key which is the pair (date, filename).

What I'd like, personally, is a way to expose any sortable EXIF data as a 'filesystem', for example `~/Photos/Longitude/122-123/Latitude/36-37/`.

Most of the commentary on a tag system seems predicated on the idea that we can't derive a large volume of tags automatically from the circumstances and provenance of the data. For instance, instead of a Downloads folder (per se, it would be a view) we could have a "downloaded" tag, which could have "downloaded-by" = "Chrome" and "downloaded-from" = "https://example.com/a-url/".

That's a lot more useful to me than a Downloads folder, especially if those tags endure when I add further metadata of the "canonical folder" variety, also known as "moving" the file.

I actually started coding a way to automatically extract EXIF data from all imported jpeg files and automatically attach them as tags to the file. That way you could search for photos taken with a specific camera, or only photos where the flash was used, or location data (if your camera had GPS), etc.. I just haven't had the bandwidth to get back to that feature and finish it.

If you don't mind some drive-by advice: I suspect you have some kind of good idea here, and I'm having trouble really seeing what it is.

I can also read from your site and comments the frustration you're experiencing in getting your product shipped, and also in explaining the benefits of it. The Internet sucks, it's a hostile place, and unfortunately leaking the bad feelings this invokes in you is off-putting to your audience.

I've had an unpublished blog post sitting around called "file systems suck" so I'm about as sympathetic an audience as you'll find. Good luck with your implementation; I'll be keeping an eye on your project, and I hope to understand it better in some later iteration of the docs.

People have been using tables of contents and indices for books and other printed materials for a long time, but those are redundant in the era of CTRL-F. At best, they're useful only as an adjunct to searching digital content.

Likewise, imposing archaic methods of organisation on modern storage is sub-optimal. The argument is to move toward something that makes more sense given the capabilities of the medium.

What tags and searching do not provide is context. One affordance that putting files into a folder provides is reminding oneself that when I look at file A, I should probably remember about file B too. Later I may even forget about the existence of B, but when I go searching for A I'm going to see B as well.

Search and tagging are not contradictory to cataloguing. They're complementary.

It's also not true that old media didn't have any search facilities. Old technical books would each have an index of keywords at the end. That's search, just analog and requiring a bit more work from the publisher. This index didn't make the table of contents redundant.