I rarely waste effort trying to remember filenames in the first place, much less needing some expensive tag curation to locate files. I simply use a bit of discipline organizing the directory structure(s). If I do ever need to actually search for something, it will be constrained to a narrow subset of directories and ignore the other 199.9 million files or whatever.

Moreover, I just don't have the problem of searching for filename fragments to begin with. Nor do I see a reasonable way to use a whole host of powerful unix techniques with a whackadoodle tiny tags filesystem. Or the need to produce a list of 20 million images in 2 seconds. What use would that be anyway? I'm not going to read a list like that - I'm going to operate on it.

Please correct me if I'm wrong, but the versatility of `find` is far more powerful if you actually need to handle/sort through that many files, and something like `fzf` probably curtails all these complaints in the first place.

Yes, why would anyone need better search or a faster, easier to organise file system? I can't think why.

Being able to think about how to order your files is a fundamental skill in this day and age and doing this on a big scale does indeed require discipline.

IMO it is just a false hope to think tags would help with the root cause of a lack of care about the data.

I'm not sure that's true, because no one does that on mobile devices. Some people have even suggested that young people who've grown up with mobile phones struggle with filesystems because they have no experience of file management despite having plenty of experience of computing.

Mobiles have shown that it's possible to remove the concept of files entirely from the user facing side of an OS.

The same is true to a lesser extent with online office suites. You don't need to know the name of a file in Google Docs - you refer to things by their titles.

Moving from file names to tags, or any meta data really, would be possible. Whether it'd be better is a matter of opinion.

I think the way Android does it is completely the wrong way around, as it makes it completely centered around apps, not documents. Making you a slave to the App, which in turn gets used to force you into using cloud services. It goes so far that you don't even have control over your files anymore, if you delete and App, the files created by that App will get deleted with it, you don't even get a warning.

I rarely use Android, but every interaction with it has been god awful. And from what I hear new version of Android will start making tools like SSHelper impossible, so you can't even workaround the madness anymore.

That is an inherent weakness of mobile OS's and prevents them from competing with traditional computers in workplaces. It works as long as you never want to do anything complicated with your computer, but most people working in offices needs the organization offered by a file system, not to mention how crippling this would be to use as a development environment.

On development environments: we manage all our code under version control, our IDE index all the sources and most of us navigate by pretty unusual ways. I guess we would be fine without any direct access to the fs as long as we had a layer that gave back streams of files we look for and a way to commit changes to git. For a lot of devs I think everything is already abstracted by their IDE.

A lot of people work the same. For instance navigating exclusively through links sent to them, their office app’s “recent documents” and the “open” dialogue with the folder they stored all their docs and might not completely understand where it is exactly (except if it’s straight their “Desktop” folder). I think a ton of adults get by with that on their everyday job.

I navigate my codebase at work primarily using the name of the entity I’m aiming to inspect or work on next (e.g. “Popup” or “uiEventStream”)

- usually using fuzzy search. This matches by file ame, but feasibly could operate by entity symbolic name to the same effect

- increasingly using VSCode’s “find references”, which already operates by entity name (at least that’s now the UI appears)

However.. I also use the file tree, because important and meaningful application structure is encoded in the tree. The tree (and its node namez) gives me sections of the app, collections of entity types, and hints how they’re connected. This is invaluable. It helps new colleagues learn the application structure and it helps old hands get to what they want faster. It forms a “silent” background context against which all entity-based decisions get made.

The structure could be encoded as tags, with all the files dumped in a single directory. I have yet to see a tagging interface work as well for tag hierarchies as a directory tree works.

Tag hierarchies are a specialised use, or extension of generalised tags. Tagging systems typically emphasise (through UI and explanatory notes) the unstructured approach. Structure and unstructure are basically opposed so making a single UI work for both seems problematic. Educating users, most of whom wont use the word “taxonomy” in daily life, how to use a tool supporting a model with an almost inherent self-contraction seems like a mammoth task.

I agree with you that a tree structure is important, the same way people still look at trees to navigate pages on most sites, going through categories, sub-categories etc.. More and more the tree is just dissociated with the actual representation, the same ways urls don’t exactly match the site structure on so many sites.

I’d imagine the tags would have some hierarchical relations if we were to use tags exclusively.

Often they have a close mapping to filesystem, but with IDE support that isn't strictly needed. (In reality however it currently is, as the filesystem is the language agnostic common interface between version control system, IDE, etc.)

... and completely cripple the user's creative powers, making him a passive consumer. you cannot get serious work done on mobile and that is as true now as it was ten years ago.

It's ok when you have a file type exclusive to an app AND the app provides export functionality. But it breaks as soon as you need to share files between apps.

Arguably, this is more about implementations than the principle, but ask any musician about the IOS music apps and they'll tell you they're great... except the file management.

File browsers got very popular very quickly on Android and there is a bundled one on there now. So mobile has shown that despite the designers attempt to deprecate files, it didn't work out.

Even my mother sorts her pictures into gallery folders. Granted – a lot of sorting on mobile happens automatically (per app).

But "consumer devices don't need an accessible file system" is not a good argument to extrapolate that to machines people use productively. Don't get me wrong, I do think we can improve filesystems in terms of usability – I just don't think having some of it in your head will go away any time soon (and if it does, it will not be an improvement).

My point is, that in a productive environment the filesystem becomes part of your brain, just like a carpenter's workshop becomes part of their brain. This is not a bug, it is a feature. You don't need to think about where things are, because you arranged your environment in a way that suits the tasks you are doing 99% of the time. Now if someone came in and arranged the tools for you, moved them around automatically by their own logic, chances are that it doesn't fit your current task, your personal preferences, etc.

Moving from a world where you blindly know where something is, to one where you have to guesstimate what another entity "thought" would be an appropriate place for the thing they are looking for is not progress. If you were to make a automatic system that can read thoughts and put the file precisely in the place people are expecting it to be – that would be an improvement, but everything else not so much.

The key difference for mehere is the one between productive work and consumption: If you are in a space where you are consuming (e.g. a food on a buffet) it is totally acceptable to not have it your way. Who cares if it takes you 5 seconds more to find the balsamico for your salad? Tasks that you don't do productively like looking at pictures on your smartphone – who cares if it takes you a minute more to find a thing? But if you are a professional photographer and you look for that one picture you took in a specific session 4 years ago not a lot will beat a well built folder structure.

Because you don't really have valuabe data on a mobile phone. It's mainly just photos, and they are all in one folder ordered by date. So adding tags to that is a feasible strategy.

Everything else on the phone most people don't consider as permanent data, so it's not worth organizing it. You contacts are in the cloud, so are your chat logs,... And app configuration data can always be recreated with some effort.

Currently teaching introductory programming at college level, can confirm.

I personally don't see folders (or traditional file organization) and tags as competitive technologies. I think they're complementing each other very well. I generally put my stuff under well defined folders, but tag the notes (or the files if I have the capability).

95% of the time, I can just go to the folder and get what I need, but sometimes I need to search something which I don't remember whether I have it or think I misplaced. In that case file indexing and search really comes in handy.

I apply these methods at least in three places very enthusiastically: Pagico, Evernote and Tiddly Wiki. Both have hierarchical organization models (It's fixed in Evernote, not mandated in Pagico, and Tiddly is just free floating by nature), but they're meticulously tagged. I rarely use search in either of these. However this doesn't mean tags save me serious time or effort. I think both ways of organization is very useful, at the end of the day.

As a pet peeve, I really don't like this strong worded titles and posts. You don't have to kill something working well to enhance it with something to make it better for some or every use case.

The docs are OCRed and I retrieve them mostly by search, with tags for a few critical docs and by approximate dates for the rest if search by content fails completely.

This is viable, and there’s no way I’ll go back to manually setting up tags and names on all the docs that we scan in case it’s needed some day. It’s like asking everyone to do inbox zero with their mail, why would you put your time in the hand of uncontrolled external forces feeding you more info day after day?

The difference is it's more likely the user will notice other tags the apply in each thing that would have been moved to 'junk' then if they had to more coarsely categorize all the junk in advance.

I get that most people are either too lazy or too technologically inept to own a computer but this race to the bottom to support everyone who doesn’t give a crap has to end somewhere. You see it with Windows UI in Win11 removing popular options so the designers can streamline the UI. You see it with this article too. Some people are always going to struggle simply because they are forced to use a computer day in and day out rather than them wanting to use it. But designing a unified system pandering for them but servicing everyone just makes the experience shit for those of us how genuinely know how to use a computer and depend on these features.

To use a car analogy (because for some reason people love comparing cars to computers…) I have no issue with track cars being sold without air con, a radio, etc because they’re a toy not a tool. So you optimise for that single purpose: racing on the track. But I sure as hell want the kitchen sink thrown into my family car.

I sometimes wonder if the problem isn’t computers but rather our assumption that everyone should be able to use a computer without training. If your job depends on using a file system correctly then you should be trained on that in exactly the same way that you’re taught how to use any of the specialist applications. In fact pre-computers, companies did exactly that with training their staff in how the filing system works!

I find tags work very well for discovering other peoples content on the web, but really don't help much with organizing your own data.

One operation that seems especially problematic with tags is copying. If I want to modify something on a file system and keep a backup, I just copy the directory tree before I do my modifications. If I copy something with tags, I end up with two things with the same tags, which is not very useful for keeping them separate.

Also how do you deal with removable media (USB, DVD) in a purely tagged system? What if the tags on the media conflict with your own tags? Once you allow filtering by device, you are just reinventing the file system again.

But I agree that I wouldn't want those pictures to be mixed with e.g. other random screenshots or drawings that I made, even if they could be separated by tags somehow. So folders as a hard separation would still make sense.

Wouldn't a shortcut to a view of un-tagged files sorted by recent basically serve the same role as an unsorted Downloads/whatever folder?

Now, imagine how many files are being shifted around on a regular basis. Temp files, cached downloads, automatic installs of software updates, all sorts of crap your IT department may remotely put on your work laptop, etc. Sorting by date isn't all that useful. At least with folders, we have an 'enforced' blast radius if random junk shows up; my temp files stay in my temp folders, install files stay where they should, system files stay with my OS, etc.

And don't get me started on how things can end up in odd places on mobile devices OSs.

The nice thing with a hierarchical directory structure is that every file has a place, even if a file is misplaced or misnamed, there is a good chance it will be near where it needs to be.

With tagging you don't really have that, it's just a pile and you have to hope that you can remember a query to make the file show up again.

The biggest problem however is that I don't see how you can actually work within a tagged system. How do you extract a `.zip`? How do you copy a file? How do you deal with removable media (DVD, USB)? Finding a file and handing it over to an app is not the only way we deal with files.

Your local file system is a work environment, where you are the one creating and modifying files. Tagging seems to works best when it comes to exploring around other peoples content, but that kind of exploration is not something I do on my local machine with my own files, since I already know where I put them.

We all know how this ends up. It ends up being like Google where the search engine uses word embeddings and the like and removes word from your search queries or replaces November by December because they are both months so you can substitute one for the other right ?

  ls **/*Plumber*

Hierarchical structures, while inflexible and sometimes prone to mis-categorization, provide navigational cues that tags don't provide. It's almost like with GUIs vs CLI - if you know what's already possible and want to express yourself precisely, you want a CLI (tags with lots of Boolean operators to precisely include/exclude). And conversely, if you don't know what's already possible, but could figure it out if you have the options laid out in front of you, then GUI (a hierarchy with all choices already laid out) will be more relevant.

Everything else is basically unsorted, maybe vaguely sorted by date of putting on top of the pile, by placing things together after searching for them once, or by 'I think I know where I saw it'.

I have tried putting everything in themed folders, it's a waste of time. The time spent searching for something is much less than the time spent organizing everything in advance. The modal piece of paper will be thrown away after a few years without ever having been needed.

I think the best system is actually a mix of hierarchy and tags. Top-level, very broad "semantic zones" (aka is this .PDF a bank statement, a cake recipe, a textbook, or some temporary file from the browser cache) would lend themselves to being represented as a shallow hierarchy, and items within a specific semantic zone could be then freely tagged or further subdivided into a hierarchy, whichever approach makes sense for that particular semantic zone.

I'm really not trying to criticise or diminish the value of your system. All I'm saying is that even without an additional tag (or hybrid tag+hierarchy) overlay, a hierarchical system can be quite useful as long it's well thought-out by the user.

That is the main problem with these so called "solutions", they usually take more effort and discipline than the problem they originally set out to solve. The right solution is just to learn the original system properly rather than trying to invent an even worse way to work around it.

I was shocked by my wife's colleagues extensive use of special characters because they wanted their file to appear first.

The proposed solution won't be any better if the average user doesn't know how to name things properly or how to search for them.

Better search? Sure! Improved speed of storage and retrieval? Great! But either show that it is not degrading current functionality or be ready for pushback from people suspicious that their current setups will break. My 2c.

what do you think happens if you make a mistake with your tags and/or there are typos in the filename? With a directory structure, you can navigate to the location and see the list of items to quickly identify what you were looking for. It is far more forgiving when it comes to poor organisation or mistakes. With a pure tag system, a file with the wrong name/tags is pretty much forever lost.

With a directory structure at least you can look into the folder of the project, see what's inside and open the files to find the one you were looking for. If you were looking for a specific Word file and only a dozen of them are present in the folder, you can always just open all of them manually to check what's inside regardless of how poorly they were named/managed. Good luck trying to find the Word file with bad tags when searching for "*.docx" return thousands of results.

A pure tag system only works for small libraries, it requires far more discipline by properly tagging every single file, it does not scale and it does not work well when you collaborate with other people. It works well in situation where you can automate the tagging (eg. a collection of pirated moves) but is pure garbage for normal files that you typically use.

It's a lot easier to tell people to place pictures of karl in the "karl" folder than it is to make sure that every single picture gets properly tagged with the word "karl". I can imagine hundreds of different scenarios where it gets tagged slightly wrong. Typos won't be easy to fix because they will simply not show up in the search when you type it. How many files with "K arl", "Carl" or " karrl" are there? no one will know.

But I was curious what this might be equivalent to in terms of time investment. A quick style guide check recommends 15-20 words per sentence for English language written communication. Assuming the low end of that, and minimal single-sentence comments, that is still equivalent to reading the entire 14-book Wheel of Time series, which tends to take most people several years, 369 times.

Sounds good, but unfortunately the article is not proposing any of that.

So, counter question: of course you need that, but how would the proposal of the article actual do anything about that?

Making tags a first class citizen would improve things immensely. The search index being a first class citizen again, would also improve things - why should I find Spotlight indexes loitering in the dark corners of my filesystem as dot files? I know there's a file index kept somewhere full of inodes and suchlike, why isn't search index data kept with it?

I also don't know why I have to rely on file system watchers that seem to be external to the file system and thus eventually sucking vast amounts of CPU when a hook into the main index would suffice. I don't write file systems so I can't tell why this is the case, or in fact, if it is the case but appears to me that it isn't every time I need to kill a file watcher.

Most of the suggestions in the article seemed good to me (immutable files, smaller meta data pages etc), I'm sure there are others around, but I'm also not sure why there's a need among some to protect the status quo by relying on good behaviour, of all things.

In other words, you have developed a disciplined habit of tagging your files. If I had a penny...

I also use automated tools to help me with the tagging but I think that it's not a magic bullet - did I claim it was?

No, and I didn't do any of the other things I asked for evidence of either.

So, if I had a penny for every time someone misquoted me I'd have a penny more right now.

Folders/boxes/envelopes in boxes. Boxes in cupboards. Cupboards in rooms.

It's easier to get to hierarchical filesytems from this. Things are found by their group, or their proximity to a more used item.

Filesystems, search, most-recently-accessed lists, an index; they are close to real life things.

In my fantasy world people would e.g. stick to .jpg, .JPG or .jpeg or .JPEG (pick one, damnit) but otherwise I quite like the tools we have.

[0] or try to

and technically, file extensions are kind of like tags. and it's really ugly that they are in the filename string. that messes up a lot of things. it would be better if they were proper tags independent of the name. so you can rename a file without changing the tags, similar to the problem with EXIF.

or more importantly, you could reference a file without that reference depending on the tags of the file. your jpg/jpeg example is also a problem caused by this situation. it would go away with proper tags

The master tag list seems to be Finder-specific preference data though.

    mdfind -onlyin . 'kMDItemUserTags=exif-stripped'

that means it is now up to the other tools to catch up and make use of them.

here is a discussion about tags and extended attributes in gnome. https://blog.chipx86.com/2005/12/07/tagging-and-the-gnome-de...

it is from 2005, so not really current, but the arguments are interesting.

in short: filesystem attributes are systemwide (but you and i may want to have different tags on the same shared file) and the user needs to have permission on the files, so you can't tag files that you can read but can't change.

i believe these issues are solvable, esp. the latter would work if we have permissions to add tags but not the content of a file. (like you can rename a file even if you don't have write permission to the file)

searching can be sped up by building an index. apps that want to use tags will need to do that, just like they build an index of files already. because searching filenames is also slow.

a version of locatedb that supports xattr would help for example, see https://en.wikipedia.org/wiki/Desktop_search

The way I organize people I know and places and all sorts of other entities I cannot physically place into boxes and folders is a lot more like the tag approach, though.

(*ba-doom-tish* for the-in-retrospect much-maligned Mitt Romney on this day)

I like the idea of having a queryable filesystem, but I wouldn't want that as a complete replacement of the directory structure.

One day I needed to remember when I had travelled to a certain city, searched on my Google photos and it instantly showed the photos I took in the city, including the exact dates.

Yes, I know letting Google know all about my life like that through photos may not be the greatest idea... but wow, does the photo search work nicely?!

I suspect a system like this would work, but the tags would eventually be used by many as a way to badly implement a hierarchy.

Gmail does not work for me.

As someone in IT I get some number of automated messages (e.g., cron). With Gmail all I can do is tag them and have a "folder" / view of just those tagged messages. But they also pollute my Archive 'folder' as well.

But I do not want them there, because they are not a priority generally, and they pollute search results.

I want an actual separate folder to file these messages in that is out of the way so as not to pollute the rest of the namespace.

And that’s the issue. The status quo may be the best choice for the lowest common denominator. But some power users could get much more out of something with a different approach. You can’t force a one-size-fits-all ontology onto the masses.

People need to wake up and realize that not all software technologies need to be popular to be successful or useful. It seems people around here assume this without even thinking about it first.

It’s funny because the author just proposed a different, I think worse due to novelty and minimal benefit, organizing hierarchy.

I think Apple has a decent approach where their spotlight indexes very well (I use hit command+space and the first letter or two instead of navigating finder), and they support tagging files.

I think this is a vastly underrated point. I am usually not interested in searching the majority of files on my filesystem. I can't remember the last time I needed to search through system files for normal computer use reasons.

I also think the author completely skips over how to handle related files. If my application needs to load a library, how does it find the file to use? If it's by name, how are name clashes handled? I suppose it could be by tag, with built-in tags, but then you won't be able to change the tags without having to change configs or the binary itself.

The treatment of immutability is too superficial to make any sense of so I don't know what the author is imagining. Ted Nelson has evolved some ideas on this for decades that might be worth knowing about. Some of which have kind of come to pass (if you squint and look at how non-destructive editing tools for video and audio work, for instance). However, very little of Ted's thinking has ever been burdened by usable implementation.

The concept of having multiple references to the same file already exists. So what he proposes can be realized with existing file systems just by introducing a different naming scheme and making extensive use of sym-/hard-linking.

Yes, a lot of file systems will have terrible lookup and traversal performance, but that problem exists in an orthogonal universe and can be solved. Is, indeed solved, in some fileystems if the marketing blurb doesn't lie.

If you think about how you would realize this using existing filesystems, by organizing them differently, the concept isn't as sexy anymore. Because it doesn't really involve a lot of new stuff and you start to see the inconvenience of having to cope with both novelty and problems you didn't have before.

The problems someone like me wants solved in filsystems are entirely different, and aren't so much about filesystems as it is about how you make the functionality useful to applications.

For instance, there are filesystems that offer snapshot semantics. Including COW-snapshots. This would be useful whenever applications need to do be able to roll back changes, switch between states, do backups while being live etc. Yet I know of no language which has snapshot as part of the standard OS interface. So people generally don't write application that take full advantage of what the underlying system offers.

I have never (never ever ever) seen a tag based system actually work once you have large amounts of files and tags - Tags are manual, often duplicated with slight name changes or variations, hard to discover, and literally worse than a folder hierarchy for discoverability in almost every way.

Tags can be nice to have - but only if I also have a path. Otherwise they are utterly inferior.

That is really impressive, but when the parent commented that they have never seen a tag-based system work with a large number of files and tags, I don't think they were making a statement of technical capability but of human fallibility.

My experience has largely been identical in both personal usage and in enterprise settings. Every time I've used a system that used human-defined tags as the primary organizing mechanism it has always ended in an unusable mess and in every case it is eventually replaced by some kind of hierarchy which usually ends up being a slightly more usable mess.

Perhaps combining them will yield the best of both worlds and perhaps with enough organizational discipline one can make a tag-based organizational system work. And I'm all for better search. But at the end of the day I am skeptical that giving normal people even more flexibility with how they organize their files will make their lives easier.

With Didgets, I decided to go with a contextual approach to tagging. Just like columns in a relational table, a tag must be defined before you can use it and all like tags are managed together. A tag can have a data type so 'Year' can be an Integer, for example. The system comes with a set of pre-defined tags, but users can easily add whatever tags they might need. That way a tag has the form 'Author = James' or 'Device = Camera'. I went further and decided each tag definition would have two levels. '.person.FirstName = James' might be a tag on a picture of someone named James. This makes it easier to search for tags by group (e.g. find all documents that have '.person.*' tags attached). By managing the tag values together, the UI can quickly show a list of values that have been used previously (and order them by use count). When attaching names to photos, it can show you a list of the most used names and let you pick one or ignore the list and add a new one.

This system is far from perfect. Users can still misspell tags or categorize them incorrectly. But this can happen with folder names in existing file systems as well.

Just to be clear, tags in Didgets do not have to be the primary organizing mechanism. It has 'Set Didgets' that contain the IDs of all members and can be arranged in a hierarchy just like folders. When importing files, the UI creates these sets (unless the user specifically turns it off) and preserves the hierarchy of the source file system.

But (in my experience) many people still seem to gravitate towards storing and navigating objects hierarchically. I can think of a few possible reasons:

First, some people intuitively think of a data element as having a location in an information space. That is, they seem to intuitively remember "where" something is by piggy-backing on spatial memory in a way that tags don't seem to trigger.

Second, navigating a hierarchy involves a sequence of constrained choices, like a wizard. Having a sequence of decisions can be especially helpful for novices. It also generally takes a predictable number of steps to locate an item which can be preferable to something that is faster on average but has slow edge cases.

Third, at each level of the hierarchy you can often display all of the options meaning we can rely on recognition over recall[1].

(You could constrain yourself to hierarchical tags and use hierarchy-like positional language such as "object is in baz" at which point I'd consider it a hierarchy.)

Of course relying on tags has plenty of upsides -- typically faster, better mental model for overlapping sets -- and large-scale data storage systems need both. But at the end of the day they don't seem to be a replacement for hierarchical systems for most people.

[1] https://www.nngroup.com/articles/recognition-and-recall/

If you've ever done online shopping, you probably have. For example, try going on Amazon or Newegg and searching for a GPU. You're shown a sidebar where you can easily filter results be certain tags such as: brand, price range, memory size, core count, in stock, energy star certified, free shipping, etc.

Simple example right now:

Go on amazon, and search for "intel CPU" - I see the following:

1-16 of 942 results for "intel cpu"

Now go back and search for "cpu", then filter by brand "intel" - I see the following:

1-24 of 835 results for "cpu"

It turns out the tags are exactly what I said they would be - a hodgepodge of things not correctly applied. For example - searching "intel cpu" actually returns items that include intel CPUs (such as motherboard + cpu bundles) that are missing in just the tagged search. But it's still absolutely a valid result if I was interested in buying a cpu.

---

as mostly an aside - I don't really trust Amazon or Newegg to be neutral in their results either, a tagged view is convenient to them as a seller where they can control results.

Home Components -> Video Cards & Video Devices -> Desktop Graphics -> Cards Search Results: "GPU"

The tags system works for specific areas. For example, tags in photo management apps are great. But they don't really work across separate domains, so what you want is top-level hierarchy, and, where needed, tags for the subtrees. That's how existing tag systems work.

You usually want more flexibility and control over how your data is projected to storage. (Say for instance you run out of storage and the scheme doesn't have any way to split the data across multiple filesystems). And you really want integrity constraints that stop you from pointing into thin air and help you clean up. Occasionally you also need to have the concept of identity (how do you refer to a given entity directly) without it being part of a projection that may have stopped existing - like a tag being deleted).

And what if I unplug the disk and pop it into a different machine? Of if you decide to move to Windows?

I do a fair bit of photography. If it taught me one thing it was that if you design software for managing lots and lots of files that craps out if something spans a filesystem border, you'll have a truly miserable time. Photo editing software used to be like that.

But datasets in general on ZFS are great because you can just mount and unmount them at will. They're there on the disk, but if you don't need them they're not mounted. This is great if you don't want to accidentally modify some subset of data you're not working with. One of my favorite features of ZFS are the encrypted datasets where you can have chunks of data stored with different encryption on the sane disk and all the integrity and migration etc works without needing to decrypt anything. Which is also great because it means ransomware can't touch it. I do think it's useful to have some sort of "chunking" of the data like that which mostly maps to ownership. This data belongs to this client/project, that data belongs to that client/project, etc. Often those divisions have different use restrictions so I've found it great to isolate things that way. And again ZFS is great at this because you can just dump out the full encrypted datasets for handoff/archival or whatever.

But anyway I would point out that filesystem boundaries come from whatever the filesystem implements and exposes to the application. The only real issue with filesystem boundaries is that renames that move files between devices aren't possible. And that's an artifact of that filesystem's design needing to synchronize the hierarchy at a hardware level. If you could call up the same path and it comes from wherever it happens to be then it's not a problem. Like in OneDrive when you open a file that's only online and it needs to suck it down first.

Let’s say you want to create a tagging system on top of a traditional file system. Let’s say you create a folder for a tag and make it have a symlink to each entry with that tag. Now any single move, delete operation will render your tag lib incorrect and there is no cheap way to correct it at each change.

I mean, it sounds like what you have described is solved for photos. I use digikam photo manager, and it automatically discovers all the photos on multiple the volumes, and supports showing files by date, location, tags, path -- whatever you like. And it is not very fragile at all -- it identifies photos by metadata-excluded hash, so moving the photos around does not break the links.

And back in Winamp days, it had an MP3 database which had basically the same properties.

I have no doubt that users could use more and better organization, but it seems like UX problem, not a filesystem one.

> it identifies photos by metadata-excluded hash, so moving the photos around does not break the links

That only solves the problem in one direction. If you run across an image after it's been moved, you know which image it is and can index into the database based on that. But if you want to find an image starting from the metadata after it's been moved, then you're stuck trawling everywhere. The metadata-hash thing exists in medical images DICOM as various GUIDs (in a different format), so you can track things and updates that using that key. But if you have to visit 30 TB of files just to find one that's been renamed or updated, it's basically impossible.

[1] http://fmri.ucsd.edu/pdf/BIDS_Presentation_14NOV2018.pdf

I know that like most folks on HN, I am not your average computer user so my view is probably a bit different. With that out of the way, I can say that I firmly prefer folder hierarchies for organizing my files over tagging. I switched to MacOS when I started my new job, and the fact that tagging is such a integral feature out of the box over plain folder navigation irks me. It's easier to save a file to the correct spot in the hierarchy and find it later rather than searching by tags to me.

Perhaps my view isn't consistent with a lot of computer users, but I will say that most people understand how hierarchical filing works better than tagging as one is more spatial than the other. After all, there is a reason that the memory palace technique for recall relies on imagining a physical space.

IME I have a number of live projects which can contain various numbers of source files, images, web links, PDFs and other documents, text files, and so on.

Then there are a number of files I access regularly which may not be associated with a project (like favourite music).

Then there's a mountain of data which is just there in case I ever need it. It includes backups of old projects, documents, music and art I keep because I think it's interesting but haven't read yet, web links that are filed and then (sadly...) forgotten, and so on.

I don't know how typical this is, and it doesn't matter. Because neither a tag based nor a tree based system address the real issue - which is designing a custom file workflow that collects related references of all kinds, doesn't confuse working data with long-term storage, allows off-site backups, allows collaboration, supports versioning on demand, and also makes it easy to find things.

I suppose all of that means some kind of process API which does a lot more than file.open() and file.close().

It could be built on tags, it could be built on trees, it could be built on some combination. Or on something else entirely.

The implementation matters a lot less than a set of available features which streamline common tasks in some fairly standardised and effective way.

It does and it's really bad IMO. The author's suggestion of unique identifiers though would introduce all sorts of new problems, primarily it would make the transparency problems of existing systems worse.

Most applications rely on the location of a file, relative or otherwise to load data (e.g. configuration). That reliance is exploited by software engineers to implement configuration swaps, event processing, and many other features. Referencing files based on UIDs, or a series of tags that aren't guaranteed to be unique or not known to be off limits to regular users, would introduce all manner of complications.

I could also see it being terribly easy to introduce bugs loading files using filtered tags. Would applications need to have relative tags to mitigate these problems? Having unique paths works both as a filter for the user and an encapsulation for a system that allows you to localize your concern. Without that encapsulation by default, you will be spending a lot more time and concern dealing with files and tags.

Tag coulds and other meta data can still be very useful. The challenge is creating useful tags/meta data automatically. For example a time stamp for every modification or a label for every application that created, modified or loaded the file. Perhaps even the applications you were using when the file was created/modified and the file names of the files loaded into the application. Train some AI to show you files you probably want given your current activity.

A big difference is that one can naturally have multiple tags, and an entity could share tags with other entities.

Sure you can use hardlinking when it comes to files, but it's tedious and you can't have multiple files hardlinked to the same path.

And yes, even with a layer on top of the FS to provide an abstraction (as an API, for instance) so you can build shells and applications, a tag + search based system would quite possibly be tedious to use.

I also don't think 64 bit ints provide a good way to definitively name things. Most people can't make sense of a list of 10 ints, but they will be able to remember at least where to look if you give them full paths.

Well you'd still have to guarantee uniqueness of the filename within the directory. For example I have several files ala DSC00005.JPG which are not identical, because the camera reset the counter every now and then.

> I also don't think 64 bit ints provide a good way to definitively name things. Most people can't make sense of a list of 10 ints, but they will be able to remember at least where to look if you give them full paths.

I agree that 64bit ints is not a stellar solution. If anything it should be an something like UUID, so it can be unique across filesystems, and something the users shouldn't normally have to deal with.

There is nothing wrong with having a userland tag management service. In fact, you'd probably want it in userspace if possible.

Implementing a proof of concept for this would have been easy if it wasn't for the fact that getting dirent to inode is fast and getting from inode to dirent(s) is very much not fast (since there is a risk that the file may be renamed).

The filebrowsers are not part of the OS.

Sure you could put tags on top of a filesystem like we do now. It's slow and require per-application support.

Little trick I learned to help sort images: Make a copy of the file in as many locations as you like, then run something like borg backup. One file, hardlinked in as many directories as you want.

Somewhat related:

Tagsistant https://news.ycombinator.com/item?id=14537650

TMSU https://news.ycombinator.com/item?id=11660492

BeOS File System https://news.ycombinator.com/item?id=17468920

TagSpaces https://news.ycombinator.com/item?id=12679597

git-annex https://news.ycombinator.com/item?id=29942796

Names should mean what, not where https://dl.acm.org/doi/10.1145/506378.506399

Unfortunaly it's not easy to get a real solution, and many people don't think that there is a problem at all (based on some comments in this thread).

Now adays I use git-annex, though it does have it's perks it seems a step in the right direction.

I can't believe how much trouble I went through trying to find the filesystem that could do everything.

I mostly use git-annex, and various tagging systems, or just git repos. Now my data is much more portable and flexible. None of these tools are perfect, but I'm using tools that are mostly good at the job.

Whatever problem you are trying to solve, you probably don't need to solve it for your entire filesystem.

SuperTag https://amoffat.github.io/supertag/

I'm all for enriching the concept of a file system with additional meta-data (in fact many files do that) but I don't think that needs to happen in the file system itself. For example, software like Picasa leveraged meta-data contained in files to provide a new way of interacting with large number of photos. The author basically proposes to put such functionality directly into the file system, but I'm really not sure if that's a good idea. Right now it's easy to move files between different systems, e.g. from Mac to Windows or Linux. If file systems become meta-data management databases that will become much more difficult.

IMHO it's because those systems just simplify, but don't move very deep in the space they opened up. If you don't offer power, then it's irrelevant which system you offer, they will all suck fast.

> Every app has its own way to store and retrieve data, there's almost zero interoperability and it's super painful to copy, paste and move stuff around (I know it has gotten better but it's still so much worse than on any desktop OS).

Which is kind of a surprise, I would think Apple would be interested to unify that space and offer a good user experience.

> Right now it's easy to move files between different systems, e.g. from Mac to Windows or Linux. If file systems become meta-data management databases that will become much more difficult.

Theoretically, it could be solved by using a meta-file-container. Something like a tar-container, which contains a file for meta-data and the actual content. We have this with specialized container-formats in media and office-filetypes. Making a universal format which would work equally well for any kind of file type could solve this problem of interoperability. This would even open up ways to improve files without changing them directly. Like adding subtitles or notes to a file, by just adding it to the container, not the file itself.

Spotlight parses and indexes all the existing metadata in your files (music ID3 tags, photo EXIF tags, etc - run `mdls` on a file in a terminal to see all the stuff it's extracted) and this could all be used to make some pretty powerful UIs, but all Apple has done is made one very handy universal search UI, and then a very poorly designed specific search UI, and then made stored searches (which are also useful, but limited in practicality by how bad the UI to create them is)

D:\masterarchive\source\YYYY\YYYYMMDD\photo file name

If I want to find a person, in a photo, I've used Google Picasa (when it was an offline product) and lately digiKam to do face matching, and tagging them with IPTC metadata tags in the photo files. Thus they survive moves across filesystems, etc.

I'm up for seeing alternatives, but there's a very high bar to clear here. People have been using directories and file storage since the middle ages.

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

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

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)

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.

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

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.

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.

There are two absolute genius inventions in computers so good and timeless that the sliced bread pales in comparison like a stupid troll comment on HN.

1. The keyboard

2. The hierarchical filesystem

Everything and anything else in input devices and data storage builds on these and the best solutions ever always are going to augment these, never replace them.

A good tag system will build on top of a filesystem and coexist with it, and offer value like stupidly fast search. Anything else will be lucky to survive a weekend of dubious fame on twitter, or up to a few months if you actively market it.

By that I mean pictures I take, papers I write, things I really wouldn't want to lose, vs 10,000 random system files.

For downloaded files sometimes the history of when it was downloaded, and from where, is almost as important as the contents.

Backups from old computers, and old phones start to pile up, and the chaos of trying to find that picture you took 3 phones ago, or the notes you took, or the recording you made, or the pdf you downloaded, or that code you wrote, or that map you made, is a real pain.

Digital clutter is one of my biggest problems.

I really need a good way to deduplicate and organize ALL my digital stuff. Tags might play a role, but I don't think they quite solve the problem.

Because I'm seeing "Windows Explorer" in background:

Windows Explorer has degraded in recent years, it is even hard to open your "home directory" and the UI is confusing. Look at the one from NT 4.0 which was much more close the fulfill the task.

And Apple:

I think the regret nowadays the howl iTunes? But instead the pushing hard on apps which contain the data. Now you have to look always into a single app and uses it facilities to retrieve a file. Android failed here, too. But using iOS is hard.

Windows clearly doesn't want people to GET to their home directory, for some reason. That seems goofy. If people don't understand that $user contains the rest of those folders (Documents, Downloads, Pictures, etc) they'll never be able to navigate on their own. That's bad.

In a sane tool that features an address bar, clicking any given directory would show, in the address bar, the path to that location. WinExp only rarely does this. If you click on, say, Desktop, it shows you This PC > Desktop, implying a relationship that is incorrect. Getting to your home folder without typing requires you to start with C: and drill down, which is objectively insane.

Even MORE bananas is that if you start at C: and drill down to Desktop, you DO get the correct path in the address bar. But if you then make a WinExp shortcut of that location, it goes back to the other behavior. WTF.

Yes. Windows prevents users nowadays from understanding a straightforward thing, file-systems. I mean it was always a bit clumsy with A:, C: and [D-Z]: and the weird desktop metaphor harmed as well.

Now I'm looking at the often criticized GNOME and the actually venerable Nautilus. They got it! All below / and in addition devices are directly usable (actually still somewhere below /run). The location bar reflects the current position. The desktop was removed because it never fit into a computer and the file system.

Some actions of Google within Chrome are also questionable. "There is not address entry field" because we don't want you to understand how the web is structured. What? File-Systems are a simple thing, hierarchical. And guess what, the web is similar. Compared to "right click", "double click" and it's new friends "long press", "hard press" and "swipe from somewhere" and "guess what the voice assistant can interpret".

I also don’t understand how a filesystem is going to store this data in such a meaningfully different way that it uses less space and/or is faster to index.

Also, the article seems to use strawman arguments. Nobody needs to remember the exact image file extensions. You just click on the "search for images group" in windows and it'll search all image file extensions for you.

In effect, tags are already there. It's just that they are automatically generated.

Filesystems have already been reduced to storage mechanisms for systems not people.

People just don’t organize files anymore. And that’s a good thing.

Most employees in relativley fresh organizations keep their files in OneDrive and Dropbox. 10..15 folders of random names and good search function that returns recent files on top. The older files just lie there, not botheting anyone because nobody is looking.

Files from other departments are found via links in Mail and Slack search - not as attachments to Email.

People launch Powerpoint (online) and use the recent files menu instead of browsing from the ”C: drive”

To rethink storage ignoring that people don’t store files anymore is futile. It’s nice for organized geeks (like me), but in general file organization is a thing of the past.

Yes, I do that too. But that's because I have to, not because I want to. Onedrive, Sharepoint (and I guess Dropbox too) are impossible to navigate otherwise, so yes, even people that understand hierarchies are forced to use an application's LRU list to find old documents.

That's not a sustainable situation. I foresee huge storage bills for organisations because they won't be able to afford to curate their growing terabytes of disorganized file storage.

- Tags in filesystem index too much. For example, if there is a program directory which happened to contain a .jpeg file, it should not be shown to user. Neither should user see files from browser's cache folder.

- Tags in filesystem index too little. Filesystems are device-specific, and a lot of times, you want to index across all devices in system. And maybe some files have no associated device at all, because they were transparently offloaded to cloud?

I think a much better fix would be to have an index database as a separate file, and filesystem providing a general support for it. Author says that the separate indexers might become out of sync or are slow -- but this is not inherent property of indexers, but rather the limitations of the filesystem design. So let's make filesystems more index-friendly:

- Make it fast & easy to detect individual file changes: every file has auto-updateable change time that user cannot mess with (linux already does this). Even nicer would be an extra timestamp which updates when content changes (not metadata) -- together with inode, this can detect renames easily and quickly.

- Make it fast & easy to detect past filesystem changes: There is a way to quickly find all changes made to the disk since some past moment: Merkle hash of directory + all contents is ideal (like ZFS maintains internally), or failing that, NTFS-style change journals can work too.

- Make it fast & easy to detect present filesystem changes: have powerful notification API that can detect all changes on disk. Perhaps also include first few kilobytes written to file for performance (so that file scanners do not have to open every just-written file)?

- Make it possible to "claim" subdirectory: something like a common attribute that advices common file browsers to avoid modifying the content. This way a software can use automatically generated names, and not worry about users just copying random files into arbitrary locations of structured hierarchy. (This should be bypassable by user with appropriate warnings -- this is UX mechanism, not security one)

- Perhaps a standard on how to store tags? All modern filesystems have attribute support, but AFAIK there is no clear consensus on how exactly it'd store the tags.

This way, one could have general tagging system, and winamp music database, and photo management app all looking at the same data and working together.

Another approach that could get at addressing this is to define frontend protocols to filesystems that do targeted, application-y things. This is done in informal vernacular often enough through things like naming conventions, but what we could really aim for is a specification that's a "form-filler" for each category, that consumes various document and data types and produces the desired kinds of metadata.

The difference between that and doing it as an indexer is that it could be seen in a bidirectional intermediation sense: if the protocol understands all the relevant formats well enough to parse them, it doesn't have to also hold a file, it could simply use internal structures and generate the file representation on demand if needed. But to do it properly these structures would have to have similar security and integrity guarantees to our current filesystems. And exposing a frontend like this does add surface area, with the silver lining of "if it's pushed down the stack, then fewer application coders will have to roll their own terrible version of this functionality".

i don't know if the filesystem layer is the best place, but i don't want to loose the tags when copying or moving files.

so somehow this metadata needs to be associated with the file, but, it also should not be in the binary stream of the file. EXIF in images and other similar metadata systems are nice, but any change there invalidates checksums or other attempts to identify changes in the actual file content. (i want to easily be able to see if two images are identical even if they have different metadata, which i can now only do with specialized tools)

But the fact is people are used to files and folders. Tools are built upon files and folders so changing everything is extremely difficult.

Plus all the tools that have tried to do things differently proved to be a pain:

1. Gmail tags: does anyone use the tag any diffrently from folder/file. Having multiple tags on an email means it’ll show up everywhere

2. Iphones didn’t have files, but it was so inconvenient it was added back

3. Microsoft relational file system was never released (i think)

I just really wish GMail archiving was a tag. For example I get my video subscriptions into a tag called "Videos" but when I am done I remove the tag and that info was lost. It would be nice if Archiving was just adding an "Archived" tag and it was excluded from tag views by default. That way archiving doesn't forget all the tags. The only workaround I am aware of is making two tags for everything like Videos and Videos-Archive. Apply both in filters then just remove one once you are "done" with them.

Folders have the same problem. Of course trash systems work around this by explicitly recording the original location.

Naming is hard work, but tagging means creating and choosing shared names all the time, with the pressure that the combination needs to be reasonably unique, otherwise you won't find stuff.

Tagging is also fiddly if you don't have a really good bulk action UI. You can think of the user-controlled paths in a hierarchy as tags, and moving files is the action of untagging and tagging. By moving 100 files from one directory nested three/levels/deep to another, you are removing 300 "tags" and adding 300 different "tags". And you can rename the "tags". A single click and drag, 600 actions, and you can see the before and after trivially, and undo trivially too (at least in Windows).

Tagging is more useful for ad-hoc "favourite" lists, and the occasional cross-reference (but it's work to hunt down the elements in the xref).

Feels like I can’t even search for a certain file type in a folder.

Really frustrating that Apple, the only company to truly master OS search doesn’t seem that interested in making the type of OS that has files anymore.

Now that you've tried Windows Search on your desktop, please allow us to help (or coerce) you to use MS Bing to search the entire world-wide-web. </sarc>

Be sure to set a hotkey for it. I use Ctrl+Shift+Spacebar since it didn't seem to conflict with anything else.

Of course before you can use Everything, you have to find Everything. Here's where:

https://www.voidtools.com/

https://sourceforge.net/projects/swiftsearch/

that uses the NTFS $MFT directly and that (if needed) is fully portable, see:

http://reboot.pro/index.php?app=downloads&showfile=609

I agree completely with your sentiment here and it truly boggles the mind.

Thank God for Search Everything.

Aren't you just exchanging the location of relevant metadata from the path to the filename?

  > ls -rec . | ? name -match <substring_in_filename>

    > ls -rec . -filter *substring*`

Even if the filesystem provider doesn't handle patterns any differently from Where-Object (?), you can save the cost of hydrating FileInfo objects only to query and discard most of them.

For multiple patterns or anything that you'd need a regular expression for, Where-Object is superior!

  find . -iname \*<substring_in_filename>*

Also, the OP solution merely sounds like a slightly altered filesystem. I thought he was going to propose something akin to WinFS, Microsoft's ploy to merge an SQL database with a filesystem, but it turned out to be a dud.

https://didgets.substack.com/p/what-is-wrong-with-you-people...

"I have invented an entirely new way to store and manage all kinds of data"

There are no references to other systems, no comparisons. Did he just ignore all the previous work? Having "digets vs X" table and a section why this time it would work will do a great thing to this projects' credibility.

For example, the Mac had “file types” and “creators” as separate metadata since the beginning. Because type wasn’t encoded in the filename, mistakes weren’t made that accidentally changed the type and you didn’t have multiple files of the same name differing only by extension. The file always opened in its creator but power users could easily change the creator. To make a successful round trip to another system, the file would need to be given the right extension and then another program would need to reassign the file type and creator on reentry. If you didn’t do it right, people would complain that they couldn’t open the document.

In addition, experience shows that organization must happen automatically or people will just let it do whatever. At this point, most users probably have all their documents in one folder and all their downloads in another. If they weren’t indexed automatically, they’d just give up and say they don’t have the documents anymore.

Come up with an intelligent way to organize automatically and it will be a real revolution. I’d like to be able to find that photo I saw a few weeks ago when I need it. I want all the documents that are similar to the one I found that isn’t the exact version I wanted. I want all the photos taken in Brazil as well as unlabeled photos that might be Brazil. I want the EPS version I have of this jpg logo

They're better understood as a memory extension system rather than a sole filing system. The idea being that it improves recall of objects if you add some attributes when saving as you are likely to use some of the same attributes when recalling.

But the vast majority of objects on a filesystem are mechanically generated and never touched by the human using it (assuming a sole user.)

The model gets much more complicated when many users are interacting with the same system.

As noted elsewhere, the flat namespace gets cluttered very quickly. I do think that there is use for a hierarchical separator since many times objects are fully inside some other concept. And when looking at massive userbases creating tags for memory, there is a distinct ordering of generic to specific when creating tags in order.

Also, filesystems also allow a bunch of workflow that aren't completely obvious under tagging. For example, a business might copy their template folder and rename it for a new customer, and inside it it has a bunch of documents with the same names. I think this a bit like having a bunch of objects (in the programming sense) thus creating things that all have the same method names (except now they are files, for example)

If Microsoft at the heyday of its monopoly power could not pull off something like this, I don’t see it becoming widespread now.

1) File systems could be modernised.

2) Files and folders as a metaphor break down when you have enough files, vs, say, search.

(1) is almost certainly true. (2) I don't think I agree with. If people use something like Confluence, things still get disorganised if people (such as me) make documents and folders in a way that's a mess, then they'll be a mess no matter the metadata.

It’d be bad if it was built by some random tech company. But it’s built by Google who I believe have some reasonable capability in search…

It’s just absolutely useless. Like: I’m a half assed php developer and I could probably knock something up that returned more useful results from a drive search.

What gives?

So, the Google Drive search implementation is probably closer to what you supposed than what you'd expect if they threw the full weight of their search expertise at it.

Yes, we can encapsulate and put a different layer on it -- tags, containers, types, relationships. However, understanding how they (the file system) work would be an immense help.

I have been teaching my daughter how files are located, added, size and why these details matter.

The blogpost talks about semantic change -- "open" would mean something else entirely.

You seem to be talking about implementation, and yes, users or programs don't care. In fact, many network filesystems like DAVFS and SMB treat filesystem as key-value store, where a single call can get any file by full path. It would be interesting to see an on-disk filesystem that is based on key/value store, but sadly the blogpost's author does not talk about it at all.

So the fundamental filesystem abstraction is K-V store. For efficiency reasons, based on common access pattern, this is often (but not always) implemented as a special kind of a tree.

The tags system builds on that and thus is higher level -- even in the Didgets, the main primitive is "open by id", an example of K-V store operations. The whole tags thing is a way to query that store.

The hierarchical filesystem also build on that -- but this time the key is (almost) arbitrary string, and the search operator does /-delimited prefix match.

There is no real abstraction change when we move from hierarchical files to tags. There is still same old underlying K-V, but we just added an alternative to readdir() (and maybe also forced every file to live in root directory)

In terms of tagging files, I feel like, with good machine learning, that can be done automatically. No human effort required. You could just search all your files with a vague natural language description of what you're looking for. Kind of like tagging webpages... Does a good search engine even care about your tags?

For example, iOS devices have a file system, but for 99%+ of iPhone/iPad users it doesn't. Presumably, the author's "Digits" object database is persisted via a file system.

Also, a user-facing file system isn't needed for things to have a location, and things can have a location without needing a user-facing file system.

You can emulate that with tags, certainly, and for some things that's a better fit (a photo can be both a personal photo and a desktop background). But what matters is that the full set of operations, including "this is no longer an X, but it's a Y" aka move/rename, and "find Xs with these attributes" must be just as fast and easy to do.

Because that would seem a great way to accomplish much of this functionality, with your choice of UX wrapper.

Current-day me would be embarrassed to tell 1993 me that things haven't really gotten much better. Sure, we expanded the 8 in 8.3, and the 3 grew to 4 or so, but I still spend an inordinate amount of time staring at a spinny widget whilst waiting for the OS to find a document.

What I want to know is how configuration management, source code organization, build systems, packaging systems, and other experts tools will work without a hierarchical filesystem.

If you're designing a camera application, sure, maybe you don't need a hierarchical filesystem if you have other means of organization and discovery. But who's going to be able to code that camera app in the first place? And when "it" is installed, what exactly happens?

Of course for any tag-based filesystem to take over it will probably need a compatibility mode. I can imagine something simple as a path=myproj/src/main.rs.

If we get rid of hierarchical filesystems, what replaces got, for instance? Perforce has some ability to project different filesystem hierarchies, but even if that were enough (it probably isn't), porting all those tools and projects to perforce would be an incredible amount of work without a clear upside for users of version control systems.

Maybe there is one, but even when I talk to experienced devs with engineering (not just software) backgrounds, I haven't gotten a good explanation. Perhaps because there isn't one?

But I've been curious about this for weeks.

The problem is as soon as you end up with a tag/search system with any complexity, you end up recreating paths/folders/whatever again. As soon as you have a multiuser system, you're forced into it.

No one has ever justified to me why i need to stop referring /etc/whatever/config or /users/username/whatever

We'd either need to scrap everything we use today, or emulate it anyways to use things like cp or mv.

The answer is both. Tags are useful, but not a replacement.

I won't necessary dislike another system to keep files organized and find them, beside a hierarchical one, but I have yet to meet one which is better than a file system.

I would also add, that how terrible is it if you have a file that applies to 2 or more areas, areas that you distinguish by folders? Eg say its a photo - you might want to have a 'family occasions' and '2019' folder - ie one photo might apply to 2 areas that you want to distinguish. Well, that level of organisation is effectively punished - you can either duplicate the photo in 2 places, or lose the reference in one. If you improve the photo using say, photoshop in one place, you better remember that you have a copy and remember to copy it over there too!

For me file systems were designed wrongly. For personal files there is the data and the meta-data. But the only meta-data we can add is in the file attributes.

Data should go into a 'bucket' and be stored by the OS somewhere, never duplicated. Meta-data relating to the file should describe features of the data, where to get it (perhaps in multiple places). It should be possible to apply multiple labels to it too, in my example 'family occasions' and '2019'.

But that's not really what I'm getting at.

Links are pretty cumbersome, get broken, etc. They sort of work in the avoiding the duplication issue I mentioned. They don't work in the sense that what the (non-techy) user wants to do with data is an afterthought - ie the order of priority is computer, then user.

What I'm talking about is that the meta-data describing personal files should be where the user adds their value to - they should be able to describe what the data means to them and that should only need to be done once. The data itself should be handled by the OS; where it is etc is not really a big concern for the user themselves.

1. It is not the implementation of a thing that I worry about, but rather how it will be misused.

We have a generally good understanding of how end users misuse the current file system hierarchy. Before adopting, or even advocating for, any alternative it would due a huge benefit to sit down and consider the ways in which such a system would be mishandled, abused, and used maliciously by end-users or bad actors.

2. Do the gains outweigh the growing pains?

In the event that the potential gains of change seem particularly appealing - and the concerns of point 1 have already been thought out and addressed - are the gains of that change significant enough to follow through on actually doing it? There are many cases where something has been vaguely improved on in some way or another across many industries, but it is a rare thing that the improvements of those changes have justified the time and investment by the participants of that industry as a whole.

So: if the primary gain of Digits is to make searching faster, does that gain of search speed outweigh the task of changing a very fundamental aspect of how computers operate today?

My personal opinion is "No, but..."

There is always room for improvement. I think that if such a system finds more ways to entice people to adopt it, to find more depth and measurable, tangible benefits of adopting it, it will have a much stronger case to make. Speed is great, but we need more than that.

---

From my perspective, I have very little issue finding files I need. I take pretty good care in keeping my files/folders well organized. I find it relaxing to organize things in a logical way. I even like organizing file structures at work, and for people in my personal life. I see this as a "non-problem" - it's a thing I actively take satisfaction from fixing.

In the event the author of the post reads this, I give you this challenge: Give me a better alternative. Give me a system that can reach the same sort of satisfaction that I get from highly organized file system layouts. Justify why I should no longer need to do that. I'm not opposed to change entirely, I just don't see a very clear gain from it, in it's current form.

In the old days, that would mean I need to do one myself. But nowadays, you assume somebody else must have done that already, so you go looking for it. If it doesn't exist, it was probably too hard, so you give up.

Or maybe you find some, but all are unsatisfactory in some way. Then you might synthesize what you like from them all, and add some private improvements, and publish that.

Or maybe you find one you really like, and you download and try it. Then you write an article, something like "The Time Has Come to Replace File Systems" or "File Systems are Racist" on your blog. Somebody posts that to HN, and it generates passionate interest. Shortly after, it appears as a module for Linux, or maybe for some popular embedded kernel used to implement USB keys. And, it's off to the races. Or, off to no more races. Or something.

That may have been true 20 years ago when the average person didn't use a computer too much. Is that still true today? Will it be true in 10 years?

Is designing a filesystem the product people's equivalent of the developer's game engine?

The problems this aims to solve are from the user layer, but the majority of files are used from the system itself. The system does not need such solutions, it's working well with the established solutions. Or is there any research in potential benefits for distributions when using a relational file system, instead of hierarchical ones?

Another point is that this would probably bring up new issues. Is there any system with real experience on this that can say what will change, what will be better, what will be worse?

But, it's also true that we should improve and innovate this at user level. Having every app separately indexing files and handling them is a poor situation. Working toward a generalized solution would be beneficial. Maybe a universal relational database layer as a foundation for all apps would make sense? Something that can have a tight integration with the Apps, and is on top of the normal file system? Thus, is would be the job of Desktop Environment to offer and integrate this.

KDE did try it at some point, but seems to have failed with it for many reasons. Maybe they should restart this, but more pragmatic and enforced, and probably in a fork as a testing ground. I remember that one problem they had, was working on multiple systems in parallel, each limited to certain apps. But there should be only one system, and it must be integrated into every app the same to be successful. KDE with it's centralized, and mature libs would be perfect to enforce this. Gnome might be able to pull something similar, but I don't know how the state of them is today. Of course this would only be a first step, but if some major DE would solve this for them, others could join it, and they could start building an independent solution. And maybe, from there, they could work toward a specialized file system that improves things even more, if really necessary.

Of course you don't nessecarily need to replace it, you can just use new tools on top of it, like you do with iOS and to some extent android. Both of those use file systems even if you never see them. But in any of those cases, you're still using a file system, with all the apparent problems that come with them, you just have an abstraction layer on top to make it easier (or at least different) to navigate.

For me, file systems are about as tried and true as you can get, they're not perfect but they do the job well enough to consider the cost of replacing them too great.

Is this true for spinning disks only or does this apply to SSDs as well? I understand that APFS tried to shoehorn SSD-like operations into the FS layer.

A bit related: I want to click on a project name and it should set up my environment ideally for that project. Filter the files, include/exclude the apps I see, filter bookmarks. Just show me what I need for this one project, not all the crud across my whole life. Where anything is linked to multiple projects, let me include/exclude at will. This would all be especially useful when I haven’t touched a project in a year or two and can’t remember exactly where everything is.

Two monitors? Project view on each, drag between them.

Imagine being able to define custom triggers that update cross reference tables when certain file system operations take place. Or, building custom views of storage system for various use cases.

Having the user shell tightly integrated would be nice too. I'd like to be able to write a query like:

  SELECT foobar2000_enqueue(t.id)
  FROM vTechnoBunkerTracks t
  WHERE t.PublishedYear > 2021

All that's old is new again...

We need storage that works everywhere and that doesn't suck. DropBox, et al, tries to make it happen but they're held back by mediating everything through the filesystem layer. Traditional filesystem concepts aren't going to make that happen.

there's the obvious inheritance factor: the parent of a child in a hierarchy can provide a _heuristic_ about properties of the child. you sort of get this with a tagging system, but the inheritance can really only go one level (unless you make a hierarchy of tags, which brings you back to tree structures)

That said folders are useful as a concept, but maybe flip things so that the folder is a tag on the file, and I can "move" or "copy" a file by changing its tags. And still present a visual folder structure by default in the file browser.

The biggest loss with this approach is namespacing... Not sure what the best option there is.

Let me jnow when you have replaced your filing cabinet with just tags.

... being sarcastic ... I think ... maybe ...

So now not only do you have a hierarchical (but optional, which is worse imo) structure for files, you also have a hierarchy for tag names (which, unlike with folders, you can't really rename if they conflict because they're singular keys).

Most of innovation on tech is not needed. Would you redesign a spoon or a fork being centuries old? No. It works.

Something like BeOS/Haiku's filesystem would have more sense, but yet useless on sharing the files with the rest of FS. Just look what happened with resource forks on Classic Mac.