The tag-based location of user documents is nice, but why do people want to put it into filesystem layer? This seems like a bad fit.
- 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.
I think most of the friction of filesystems stems from wanting application layer features in a construct that has always been decidedly "systems" and just holds data, while applications themselves have gone the route of appending more and more features into files. Since there's no middle layer, files have increasingly become the Armstrongian "gorilla holding the jungle and a banana", often duplicating state and metadata to get the job done. And it terrifies me when development tools, as they so often do these days, spray around files, because it usually results in broken dependencies somewhere down the line.
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".
Don't recent Androids do your "frontend protocol" idea? At least a file chooser on my phone, in addition to a regular file browser, also has an entry for "google drive", which seems to have no corresponding physical location.
Another thing you'll want for database-centric file stores, that should be table stakes for every desktop OS, is Amiga style datatypes. That is, allow applications to register readers and writers for their file formats. That will help the database parse files for important metadata.
I keep wanting to write a basic implementation of datatypes combined with a fuse filesystem to allow access to metadata and transcoding from unaware applications, then realise I don't have time and hope someone beats me to it. Please, someone, beat me to it...
The tag-based location of user documents is nice, but why do people want to put it into filesystem layer?
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)
This post is full of interesting new ideas. I'd love to see these implemented in a mainstream Linux distro (or Windows/Mac), but the backward compatibility considerations are a huge impediment. Literally all the software in the past 4 decades (at least) has used directory and file based file systems.
One way to encourage usage and let developers find advantages of the new system could be to offer this as an alternative file system that can be used in parallel with existing ones. That would also uncover bugs/problems in the new system which could be fixed.
PS: I do think the name "didget" could be improved. It is not as natural to write or speak as "file".
Is it really full of new ideas? This looks like a fairly generic tagging system which seems to pop up on HN every few months.
If you are interesting in tagging systems, I recommend you to look at Microsoft WinFS (part of Longhorn). This took idea of tags very deeply -- not only it had user-specified tags, but it would parse many existing file formats and automatically generate tags based on contents -- for example, if it saw a word doc and detected it is of "resume" type, it'd extract "Name, Educational Qualification, Experience" values from it.
I use the name Didget (short for Data Widget) because it encompasses much more than file data. A 'File Didget' is an object where its data stream has unstructured data and is unmanaged by the system. But there are other Didgets (Schema Didgets, Set Didgets, Tag Didgets, etc.) where their data stream contents are completely managed.
Like NTFS that uses files for its internal data structures and many databases that use relational tables to manage databases, I chose to enclose all my internal structures (e.g. tags, file tables, allocation bitmaps, etc.) within other Didgets.
His CV says he worked on NFS for Novell for 7 years and then PowerQuest (who made PartitionMagic, DriveCopy, DriveImage, and ServerMagic) for 6 years. He's clearly not a rank amateur.
While true it's not impossible for engineers to make mistakes, even experienced senior engineers.
I think the mistake here is perhaps the idea that what is proposed are actually problems that need solving. The idea of indexes being managed by the OS is sort of handwaved away in the article because: "they have to store their indexing information in a separate database. It is easy for the database to become out of synchronization with the file system. Also, to speed up the indexing process, users often only index a portion of the file system so using the index might not turn up the file(s) you were looking for."
A second mistake is thinking it's possible to solve the "what is this file" problem:
The metadata record does not have a file classification system. To determine what is in a file, the file name or the data stream must be examined.
This will always be true. You can make a best effort based on some indicators but it will always be prone to problems. What ever system you create that you believe will address this problem will be prone to failures, almost by necessity, because a "type" of a file is largely a philosophical thing that everyone pretends is technical. Even if you solve for 90% of cases, you're still going to have enough problem cases that it won't be reliable. It may work for simpler cases like text files, videos, zip archives, and images. How do you classify a docx though? Is it a zip file? A "document" file? Is something Javascript just because it ends in .js?
Is adding this level of overhead to writes useful? You can see in the video his test framework sets up "hundreds of millions" in seconds and yet copying actual live data from his Program Files directory takes 1m10s for 24,431 files. This suggests to me that at the minimum the "hundreds of millions" of objects are not representative of real live data, since that takes approximately 2 seconds to create.
I'd also suggest that if this is truly innovative and these problematic things from the presentation are actually just artificial and that it is doing things under the hood, it should be using a true OS filesystem browser to do this same work. To convince me it could replace standard filesystems, demo me an implementation of the OS running on it, or at the very least using it as a storage drive.
It would’ve been really interesting if WinFS actually was released. It had a very interesting type system. Probably would’ve been more suited for servers than desktops/clients.
I wouldn't be surprised if Microsoft could have pulled it off if they had designed the system from the ground up. Instead they tried to do it on the cheap by taking two existing systems (NTFS and SQL Server) and combine them in ways they were never designed to handle. The product was either was too slow or too fragile (or both).
This has completely changed the way I use files. I rarely ever open the explorer to navigate to a folder, but instead open everything to search for a file and then instantly jump to the file location. Naming files well becomes much more important than where they are located.
Spotlight on mac. I use recoll on my Linux machine and let it update every few days. Fast local file system indexing is amazing and abstracts away a lot of file system pain. You often don't even need to name files particularly well to find what you want if you index file contents as well.
For simple matches against one pattern, you may prefer...
> ls -rec . -filter *substring*`
... as filtering can be offloaded to the "provider" when Get-ChildItem (ls) knows about it.
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!
Thanks, I'm not usually doing performance required stuff but when I write a function I always want to know the best way to feed the pipeline, I appreciate it. #snoverville
Yep, Everything is a game changer. I don't worry much about where a file is any more, I just worry about giving it a good filename. Then I will always be able to find it, wherever it is.
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:
Boggles the mind how Windows search basically just doesn’t work at this point compared to what you have on other operating systems.
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.
>> Boggles the mind how Windows search basically just doesn’t work at this point
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>
Everything is a lovely tool, but I'm continually amazed that it should have to exist at all. Why is the Windows built-in search so atrocious? You literally cannot use it as part of a getting-anything-done-at-all workflow. And it keeps getting worse with every update? Why would I want to mix Bing search results with stuff from my filesystem?
"But he has nothing on at all," said a little child at last. "Good heavens! listen to the voice of an innocent child," said the father, and one whispered to the other what the child had said. "But he has nothing on at all," cried at last the whole people.
I agree completely with your sentiment here and it truly boggles the mind.
The idea of building “indexing” into the file system means either the file system directly understands all file types, ignores those it doesn’t understand (thus requiring an out of fs indexer), or requires the file system itself to be able to dynamically load logic to handle different file types. By the time you get to the last one all you’ve done is build spotlight(or the ms equivalent) into your file system, so now you’ve got all the cost of the indexer only now it’s in the process reading and writing the raw bits, and of course doesn’t index contents of any other filesystem (so you’re still going to be running an indexer).
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.
His numbered list of issues makes perfect sense. And apparently he has solved all of those problems?
This feels like one of those projects that corrects some structural flaws in the status quo.Therefore it should be commended and adopted.
However, since the judgement and behavioral patterns of most humans is very similar to that of ruminants, the likely response will be indifference or hostility.
Not sure if you are joking or not, but no, his numbered list of issues does not make a perfect sense.
Item 1 is irrelevant -- one very rarely cares about fixed-size metadata record for file, because one doesn't normally cache metadata for each file on filesystem in memory. Items 3 and 1 contradict -- if the file record has an arbitrary number of tags, it cannot be fixed-size. Item 4 is solved by MacOS (via access-via-inode) and Windows (via file tracker service). I cannot quite understand what he means by item 5 but maybe he is talking about Windows not having trusted "ctime" field? If so, this just Windows' problem, all Unixes solved it long time ago.
You may want to check the technical merits before recommending the project for adoption.
I'm sorry, but this sounds like my 13-year old daughter rambling about why her desktop has become complex and why not be just like the simple iPad. However, we may not like it; there will always be a file system - for things to have a location.
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.
Well, on the one hand, I tend to agree, but on the other hand, we should explore these concepts more deeply. The Von Neumann computing architecture hasn't changed in like 80 years and is still pretty darn dominant. I am fine with people exploring this space without dismissing them out of hand. Sure, file systems don't seem like they are going anywhere in their present form, but this is how we advance computing. Paradigm shifts can and will happen, eventually.
To me, what makes hierarchical file systems compelling, and what a replacement needs to be able to achieve, is that it provides logical filtering. E.g. I rarely want to search all image files on my machine. I want to search screenshots or personal photos or desktop backgrounds. For some categories, like my source code, the hierarchy is deeper.
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.
You say that like the file system is the ground truth to how we use a disk. It is nothing but another abstraction we've invented to manage blocks on some persistent medium. The vast majority of people wouldn't notice if you replaced their FAT partition with a key-value store, where the keys were paths delimited by slashes (with some UX to traverse paths).
Are you confusing semantics (open, readdir, cwd, ".." etc..) and implementation (directory entries, ".." pointer, etc..)?
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.
The point I was trying to make was that the directory hierarchy isn't fundamental to how people reason about their data. That you could introduce a little UX over a KV store and those that wanted to mimic the old abstractions could continue to do so. But we could also change the abstractions (like the blog post says) to something like tags, and it wouldn't be any lower or higher level, compared to what we have now.
All the "tags" systems I have seen rely on some underlying store -- like in database-based methods, there is main table data (K-V store) and indices (another K-V store); or in symlink-based tags, we use underlying filesystem as data store.
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)
Files seem like a pretty natural abstraction: a blob of data, an array of bytes that forms a self-contained unit. There's something that seems natural about that. You can attach all kinds of meta-data to files, but then you run into the issue of which types of tags people care about or are supported by different OSes, etc. The idea of hierarchically separating files, and giving them names, and also types in the form of the extension, seems like a pretty good system to me.
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?
I think you're talking about file systems as an implementation detail, whereas the author seems to be talking about file systems as a user experience.
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.
iOS strongly opposed exposing the traditional file system but eventually caved in (with the Files app), as for non-trivial use cases it is simply the better way.
This looks pretty neat (though i will not easily give up files). The author seems pretty frustrated in another post that few people are interested. I am willing to give it a look over at the design+play with it, but i struggled to even find the website, and on said website there is no way to download the software. I only found a sample data archive.
In the comments here, people named dozens of similar systems. I am sure that in the previous discussions (that must have prompted that frustrated post) the same happened. Author must have read them.. and then went to write:
"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.
The hierarchical folders-and-files metaphor/implementation is second on my list of software paradigms that need to die. And I say that as an "if it ain't broke, don't fix it" guy who does not jump on bandwagons and want to replace everything every other season with the new new thing.
Why? Hierarchies seem like a natural fit for the human mind. We can know only the relevant parts, which might change according to what we're working on and confidently exclude entire large complex branches like the contents of C:\Windows or some program's temporary working files or whatever from our awareness.
They also combine in an obvious way. If you mount another filesystem somewhere, it's contained in that somewhere, not mixed in with the existing one in some unexpected complex way.
They're not a natural fit for real world data, but there's a tradeoff between serving humans and serving nature.
> Hierarchies seem like a natural fit for the human mind
I'd argue they only seem that way because we've been raised and taught to use them but haven't been taught sufficiently to think about other ways to organize knowledge.
> They're not a natural fit for real world data
In "A City is not a Tree"[1], Christopher Alexander discusses the semilattice in relation to city planning and human societies. Clay Shirky has previously noted[2] that categories and ontologies are too brittle to serve human thinking.
As an example of an ongoing attempt to create a hierarchical ontology that isn't helpful, look at any list of music genres. Also note that social networks are not organized hierarchically – humans have the ability to handle interconnected structures just fine.
This also relates to why many people don't understand or can't quite relate to true distributed peer-to-peer computing or systems where there is no central controller or fail to grasp emergent behavior. But nature is fine with completely decentralized systems: see, for example, foraging ants. See, for example, Emergence: The Connected Lives of Ants, Brains, Cities, and Software by Steven Johnson
Reading this article left me wondering just where the 200 million tags this guy needs are supposed to come from. Manual curation?! Automatically derived by file extension? file headers? what is the cost of opening a file, parsing its filetype, comparing against a reference, writing it to a database, etc. How is that cheaper than current indexers (which all seem to work fine btw)?
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.
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 sounds somewhat like “gmail for files” which is … problematic because email search works well enough because it’s relatively rarely done.
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.
Google photos is pretty amazing. I enter a search for "car" and immediately can see the photos os several of the cars I've owned over the years.
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?!
The google photos image search is amazing. The other day I was trying to remember how long it had been since I smashed my toe doing yard work so I tried searching “toe nail” and it pulled up exactly the picture I was looking for.
If I had a penny for every time someone on HN responds with something like this - "just become more disciplined and you don't need X" - I'd be a millionaire. Doesn't matter what it is, type systems, memory safety, a better UI for Git… there's always someone ready to chime in with how their workflow means these problems don't happen, or, even better, asking the question why would anyone need this?
Yes, why would anyone need better search or a faster, easier to organise file system? I can't think why.
Having every file pollute a global namespace seems to require more discipline than the current hierarchical system where you can easily copy a directory tree without having to worry about breaking something else.
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.
Yeah, you can see the downside in the demo video. When he shows off the search for pictures, there's a random mixture of actual photos and things like toolbar icons and whatnot. Sure, you could fix this by tagging everything and doing a more complex search, but that sounds like a lot of work and discipline, more than eg the guy doing the demo was willing to put into it.
Actually no. I wanted the demo video to be short (4 minutes) so I didn't do a lot of complex searches. I have other videos, but to show everything takes a 20 minute video and I didn't think that was a good length for an introduction.
Because such a system would entail its own drawbacks, such as a larger CPU load or a more fragile disk organization, whilst most people wouldn't really need it.
i try to organize my stuff, but sometimes i forget where in the organization i put something. then a brute-force search helps. if i keep good directory and filenames, then locate will do the trick. once i found one item, any related other things are usually nearby.
> Plus, this is how we organise [0] stuff in real life.
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.
folders are more convenient because they are part of the file system. there is no ls by tag or even a gui filemanager that shows files by tag. that's one reason why tags need to be part of the filesystem, because if they are not, then most filemanagers would not support them.
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
macOS does store tags in the filesystem (which you can access using xattr at the command line) but I have no earthly idea how you find files by tag or really do anything with them.
The master tag list seems to be Finder-specific preference data though.
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)
xattrs can certainly be used to store tagging info. There are a couple major problems with them though. 1) xattrs are not supported by all file systems and they are not enabled by default in some. If you copy a file with xattrs from one file system to another that either doesn't support them or didn't enable their use, then your xattrs are thrown away in the copy. 2)Searching for files based on xattrs in a large folder tree (e.g. several million files across thousands of folders) is exceptionally slow by nature.
right, but the alternative is no support for tags at all, so xattr gets us halfway there, and filesystems that don't have it need to keep up.
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.
I’m all for optimising usability but there comes a point where one over optimises. While I love the app-orientated design of Android and iOS (ie you share data between apps rather than apps sharing a file system), they are effectively toy OSs for toy devices. Sure some people are hugely productive on them these days but they’re the exception rather than the norm. Whereas I depend on a file system to organise my data. In fact the file system is directly interpreted as name spacing in a number of different programming languages.
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!
A better search and tagging can be valuable tools. But no matter how good search gets, it will not stop users from putting files untagged into one big junk folder.
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.
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.
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.
> Mobiles have shown that it's possible to remove the concept of files entirely from the user facing side of an OS.
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.
We have systems, but they don’t need to be “files”.
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’m still largely pro-file-systems, but your comment made me think. Here’s some loose thoughts, just to get into the problem space.
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.
Many programming languages have a tagging system for that: namespaces, packages, etc.
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.)
To add to that, there is IMO a renaissance of “fuzzy” navigation, with macos’ quick search (the Sherlock/quicksilver clone), and tools like Obsidian spreading the model of moving to apps and file by a set of partial keywords.
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.
> Mobiles have shown that it's possible to remove the concept of files entirely from the user facing side of an OS.
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.
There are two main places where Android apps store files: within an application-private slice of the main filesystem, and the shared /sdcard (which, as its name implies, was originally a removable SD card, but nowadays is just another slice of the main filesystem). What the parent is complaining about is the former (and a per-application directory on the later), which is removed whenever the application is uninstalled (or the user tells Android to clear the application state); and unless you have root on the phone (or are looking at the per-application directory below /sdcard), or the application explicitly exports it, it's not even visible to any file explorer.
> Mobiles have shown that it's possible to remove the concept of files entirely from the user facing side of an OS.
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.
> Mobiles have shown that it's possible to remove the concept of files entirely from the user facing side of an OS.
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.
I strongly doubt that regular users ever bothered to use Android's file system.
If there are even files involved, most people will just use the app that received or created that file to interact with it. Especially since apps sometimes put files in completely random places, that even I as a technical person have trouble finding.
>Mobiles have shown that it's possible to remove the concept of files entirely from the user facing side of an OS.
... 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.
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.
Let's remove street addresses altogether, because that requires hard memorization, right? Instead let's all put any house of a city all along a contiguous space and refer to them via a description of their appearance.
> 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.
Currently teaching introductory programming at college level, can confirm.
I don't disagree with your premise that mobile abstracts away the file system. However many people do put rather a lot of effort into organizing files on mobile. I clean and sort my downloads folder just like on my computer, but more importantly the majority of people I know use folders to handle the now thousands of pictures we generate on mobile.
> I'm not sure that's true, because no one does that on mobile devices.
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.
I’m on the side of peoples who gave up on organization entirely, and have a stream of scanned documents with only the scanned date as the title for 99% of them.
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?
> But no matter how good search gets, it will not stop users from putting files untagged into one big junk folder.
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.
> But no matter how good search gets, it will not stop users from putting files untagged into one big junk folder.
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.
By analogy: if you were to store all your paper copies of bank statements, bills, mortgage papers, etc... Would you just dump them in one big pile in the middle of your living room, or would you sort them into vaguely themed folders to impose some organisation? Hierarchical filesystems are valuable to those that want to organise data in ways that tags can only emulate.
Can I shout "Plumber invoice 2021" at that pile and the right document will come flying out? Or just "invoices 2021"? A pile that could do this would probably be fine for me.
As long as you know exactly what's in the pile I guess? A good folder/directory structure tells you pretty quickly what you've got available and makes it easy to browse and explore even if you've got no idea what you might find going in.
They could help if the tags were 'Occupation = Plumber' and 'Name = Joe'. Now a search for all files where both tags are present will get you Joe the Plumber's invoices. If you want everything from any plumber or from any person named Joe, then just leave off one of the tags from your search. It is very much like when querying rows in a relational database, just adjust your WHERE clause.
I agree. Unfortunately, right now the 'well structured relational database' is completely separate from the file system. Didgets was designed to combine the two into a single coherent system so that you can't update one without the other. By 'combining' doesn't mean I did what WinFS tried to do and just take a filesystem and a database and stick them together somehow. I built a completely new system from the ground up that incorporates traditional filesystem features (block allocation, stream management, metadata control, folder hierarchies, etc.) with solid relational database features (schema, tags).
Do you mean Joe the Plumber from London, UK or Joe the Plumber from London, Ohio ?
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 ?
It gets annoying though when you have just single invoices or documents that don't quite fit in your structure. I eventually started throwing all received documents in one folder and used the name as tags basically. E.g. 20210214_plumber_invoice.pdf or 20181204_someshop_invoice_playstation.pdf...
(And yes I use the filename for tagging because I don't trust e.g. Windows tagging system to be there forever or be copied properly onto other operating systems.)
The difference is that if a file isn't sorted in a file system, it just sits on your Desktop or Download folder and is still easily visible. If you use tags and your file doesn't get tagged properly it just is lost in the pile and impossible to retrieve.
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.
> "The difference is that if a file isn't sorted in a file system, it just sits on your Desktop or Download folder and is still easily visible. If you use tags and your file doesn't get tagged properly it just is lost in the pile and impossible to retrieve."
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?
The lost file might not be recent and it might not even be untagged, it might just be tagged incorrectly (e.g. `vacation-2019` vs `vaccination2019`).
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.
Anecdotally, my short answer to this is 'no'. At least a Downloads folder has a loosely defined purpose. I have often gone back to try and find something I downloaded that's no longer available (or too big to download again), and it's tricky at best to find something already.
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 solution should be a combination of folders and tags. E.g. imagine a folder that just contains all your photos without any substructures. It would be easy to just select e.g. all "2018 photos", "birthday photos" or "photos of your parents" in there without needing specific subfolders for those things (especially since those subfolders would conflict with eachother).
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.
If your memory is anything like mine, chances are you momentarily don't remember the word "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.
I keep passports, degree certificates, deeds, health insurance docs.. the things I would grab if I was running out the door, in a single box file.
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.
Is that not effectively a first-level hierarchy with no further subdivisions? The "important stuff" category and "everything else" category are already a useful taxonomy, even if very minimalist.
One of the biggest problems with folder hierarchies is that files can often be classified in several different ways. To take your paper statements analogy, do you organize by year, by institution, or by category? What if you have a 2002 bank statement? Do you put it in the '2002' pile or the 'bank statements' pile? Using existing file hierarchies allow you to store the digital document in the '2002' folder and then create a hard or soft link in the 'bank statements' folder, but that can be a hassle. Tags allow you to attach them to documents, photos, videos, etc. without worrying about how you might organize them. Luckily, Didgets lets you organize your file using either a hierarchical folder structure or just by using tags. It is your choice.
To me, it seems best to exclude as many possibilities as I can during each step of the (naturally recursive) search. Filtering by "is bank account statement" excludes a lot more files than "was incorporated into my files in 2002", since most people only have a few bank accounts but a lot of photos, videos and other things that they create or download in a given year.
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.
You assume that there are fewer bank statements than 2002 files in your argument. What if you loaded in a million bank statements in 2005 but only created a few thousand files in 2002? With Didgets, I can tell how many objects have each tag attached so I order the search to eliminate based on how likely the set I am searching for has each tag.
How many bank accounts does an average person have? Even for the most extreme cases, we're looking at the low hundreds of statements annually, at the maximum. If you're not an average person but instead a business or an archivist, then you need a custom system anyway.
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.
Surely that's the tagging. I use tags extensively on my Mac because it's so useful to me but it's clearly an afterthought for Apple, and I struggle to use it at times.
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.
Where's the "don't need X" part? Have I dismissed hierarchical file systems out of hand? Where did I suggest greater discipline should be the approach.
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.
With Didgets, tags are an integral part of the system. They don't get lost or forgotten when you copy a file from one place to another. Searches are a native part of the system as well so you aren't relying on a separate indexing service that has its own database somewhere else.
BTW, managing file data using folders and tags are just a few of the features of the system. I found out the columnar stores I used for tagging, were easily used to also form relational tables. I can load in a 100 million row, 40 column table and do queries against it much faster than the same data loaded into Postgres, MySQL or SQL server.
The article proposes to replace the current file system approach (which works just fine for me, by the way, thank you very much) with something different to solve a problem that I (just like the post you reply to) have no interest in.
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.
I guess the point is, the proposed system wouldn’t actually be easier to organize. The metadata that would make searching so easy is what’s missing. But a new data structure doesn’t solve for the missing metadata. And without that extra metadata, searching would not actually be improved.
This is obviously hyperbole and you're well aware you haven't read 100 million Hacker News comments, let alone that many with exactly the same basic message.
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.
don't you think a tag system would require even more discipline?
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.
Not necessarily. Missing or misspelled tags could be discovered just like a row in a database that has a column value that is missing or misspelled can be. For example if you want all your photos to have a 'Year' tag attached for when the photo is taken, just query for all photos WHERE 'Year = NULL'. The same goes for values like names. If you see that you have 10,000 files that have 'Name = Karl' attached but only one that has 'Name = Kral' attached, then that is an easy fix.
With only a few hundred file, it's easy to look at the list and spot the outliers. In a real world scenario, how would you know that a few dozen files are missing when you search for "karl" and the files tagged with "Kral" don't show up? On a small file collections that only you has access to, you might remember them and notice that they aren't part of the results but that doesn't work for large libraries or if multiple people are collaborating.
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.
Cleaning data for tags is about the same as cleaning data in a relational database table. Here is a demo video of how Didgets does that: https://www.youtube.com/watch?v=kqkNeU1LYEQ
Just think of each defined tag as one of the columns in the table.
If you were trying to find a physical copy of an important tax related letter, would you prefer to search for it in a folder dedicated to tax document from that year or from a room filled with every single piece of paper that you have ever received by mail in your life?
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.
There seems to be a lot of confusion here about Didget's tagging system. It is not meant to replace the file hierarchy, but to supplement it. With Didgets you can still organize all your files in a plain old folder hierarchy without tagging everything. Tags just provide a secondary way to search for things. So you can still stick all your photos of Karl in a folder named 'Karl' if you like.
The core problem at keeping the files organized is that unless you are dealing with a stream of effectively pre-tagged files, tagging/categorizing/grouping emerges after sufficient number of files arrive. Therefore organizing is proactive
My response to these types of proposals is “just imagine that folders are tags and each level of hierarchy is a tag, symlink for multiple tags.”
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.
> it will be constrained to a narrow subset of directories and ignore the other 199.9 million files or whatever.
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.
When importing files into Didgets, the program automatically gathers information from the source file system and attaches specific tags to each file. For example, the file name is attached as a 'name' tag. Each folder name in its path is attached as a 'folder' tag. The file extension is attached as an 'extension' tag. In addition a SHA1 hash is created from the data stream and attached as a tag. You also imported them by dropping the files or folder onto a 'drop zone' on the create tab in the GUI. Any tags attached to that drop zone are also automatically attached to any file dropped on it. So dropping 100 photos on the 'My Wedding' drop zone might attach the tags 'Event = Wedding' and 'Year - 2022' to every photo. Searches for files that have a tag 'Folder = Microsoft' would find every file that had 'Microsoft' as a folder anywhere in its path.
Let’s replace something that works with an unknown just because time has come is like saying let’s replace transportation with teleporting except that we’re in 2022 and we don’t even know if it’s still possible.
And I can rip `find -name` through a 4TB SSD pretty quickly. Usually only a subset is required, because I remember roughly where it is.
For my NAS I spend a bit of time on keeping files organized.
I don't generally want full-text search either, it tends to be cluttered with crap and I don't use full-text indexers (invariably they seem to decide to reindex whenever I least want them to).
The problem of hierarchical file systems and data location is a really old problem that has had many implementations (I even tried building one many years ago).
The pattern that has worked out really well for me, is to just organize my data into specialized collections, and not worry too much about the underlying filesystem.
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.
The pessimism here is ridiculous. I thought the demonstration video was pretty cool, seems like the didgets concept is more sophisticated than meets the eye. Open your mind a little, people.
Sometimes a bad idea comes back from the 1970-90s and people here are on average young enough they start falling for it again.
But the last serious shot at this was recent enough and a big enough disaster (Longhorn's WinFS), and/or a few years into iPad ownership when people started wanting to use it as a more serious computing device with an awkward few years until it got "file management" (it always had an FS). Both are too recent. Try again in another 10 years.
First off, this is clearly just a promotion for "Didgets"... which seems like a cool idea, but the problem is the article presents a solution by framing normal-computer-user file organization as a problem to be solved (it really isn't). OP does this instead of identifying an actual use case. OP - you are losing people this way. Normal users do not have "200 million records" they are trying to search for by file type or name. Get a better pitch than this for whatever you trying to solve.
> If you have ever forgotten where you stored a file in a file system
Nope, never happened to me.
> File systems let you store any file in any folder, regardless of whether the folder path is appropriate for the file
YES, exactly, that is a feature, not a problem. If it is not appropriate for the file, you only have yourself to blame for putting it there in the first place.
> Even if you remember some parts of the file name
> searching by file extension may or may not turn up the file you were looking for
Who searches for file by name? Names mean nothing. You find the file by navigating down the relevant hierarchy based on what you are looking for.
By file type, are you kidding me?
A hierarchical file system is ideal as the basis of file organization. Tags and search can be added on top of that (and admittedly have room for improvement) if you really struggle to handle organizing your files by yourself (or some unstated use case the OP has in mind).
I'm struggling to figure out how the OP operates... at some level they seem like a computer illiterate person who saves everything to the desktop then struggles to find stuff. But, I'm sure that is not actually the case... so do they just fail at making an attempt to organize? I'd be interested to better understand what type of files they have so many of that they have to resort to constantly searching by file name or type and need a faster way to do that.
I'm sorry if the article came off as such. I meant to start a discussion about the shortcomings of filesystems and get people to look at possible alternatives. I think what I built (so far) has some great features, but it is entirely possible that the eventual replacement for file systems will be something much different. I spent years working with filesystems and databases and came up with a long list of shortcomings I saw in both. I don't pretend to know all the answers, but I also don't like people dismissing ideas without taking a serious look at them.
I'm always excited to see and learn about new and different concepts, but I struggle with two main points:
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.
I’d love this. Been wanting something better forever.
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.
301 comments
[ 4.2 ms ] story [ 282 ms ] thread- 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)
One way to encourage usage and let developers find advantages of the new system could be to offer this as an alternative file system that can be used in parallel with existing ones. That would also uncover bugs/problems in the new system which could be fixed.
PS: I do think the name "didget" could be improved. It is not as natural to write or speak as "file".
If you are interesting in tagging systems, I recommend you to look at Microsoft WinFS (part of Longhorn). This took idea of tags very deeply -- not only it had user-specified tags, but it would parse many existing file formats and automatically generate tags based on contents -- for example, if it saw a word doc and detected it is of "resume" type, it'd extract "Name, Educational Qualification, Experience" values from it.
Sadly, there is no good single overview I know of. You can start from wikipedia (https://en.wikipedia.org/wiki/WinFS) and follow the links.
Like NTFS that uses files for its internal data structures and many databases that use relational tables to manage databases, I chose to enclose all my internal structures (e.g. tags, file tables, allocation bitmaps, etc.) within other Didgets.
I think the mistake here is perhaps the idea that what is proposed are actually problems that need solving. The idea of indexes being managed by the OS is sort of handwaved away in the article because: "they have to store their indexing information in a separate database. It is easy for the database to become out of synchronization with the file system. Also, to speed up the indexing process, users often only index a portion of the file system so using the index might not turn up the file(s) you were looking for."
A second mistake is thinking it's possible to solve the "what is this file" problem:
This will always be true. You can make a best effort based on some indicators but it will always be prone to problems. What ever system you create that you believe will address this problem will be prone to failures, almost by necessity, because a "type" of a file is largely a philosophical thing that everyone pretends is technical. Even if you solve for 90% of cases, you're still going to have enough problem cases that it won't be reliable. It may work for simpler cases like text files, videos, zip archives, and images. How do you classify a docx though? Is it a zip file? A "document" file? Is something Javascript just because it ends in .js?Is adding this level of overhead to writes useful? You can see in the video his test framework sets up "hundreds of millions" in seconds and yet copying actual live data from his Program Files directory takes 1m10s for 24,431 files. This suggests to me that at the minimum the "hundreds of millions" of objects are not representative of real live data, since that takes approximately 2 seconds to create.
I'd also suggest that if this is truly innovative and these problematic things from the presentation are actually just artificial and that it is doing things under the hood, it should be using a true OS filesystem browser to do this same work. To convince me it could replace standard filesystems, demo me an implementation of the OS running on it, or at the very least using it as a storage drive.
And this application of it acts as a literal indexing service.
It's a *long* way from :
> ...time has come to completely replace file systems with something better!
If Microsoft at the heyday of its monopoly power could not pull off something like this, I don’t see it becoming widespread now.
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!
Aren't you just exchanging the location of relevant metadata from the path to the filename?
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
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>
I agree completely with your sentiment here and it truly boggles the mind.
Thank God for Search Everything.
Because that would seem a great way to accomplish much of this functionality, with your choice of UX wrapper.
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.
This feels like one of those projects that corrects some structural flaws in the status quo.Therefore it should be commended and adopted.
However, since the judgement and behavioral patterns of most humans is very similar to that of ruminants, the likely response will be indifference or hostility.
Item 1 is irrelevant -- one very rarely cares about fixed-size metadata record for file, because one doesn't normally cache metadata for each file on filesystem in memory. Items 3 and 1 contradict -- if the file record has an arbitrary number of tags, it cannot be fixed-size. Item 4 is solved by MacOS (via access-via-inode) and Windows (via file tracker service). I cannot quite understand what he means by item 5 but maybe he is talking about Windows not having trusted "ctime" field? If so, this just Windows' problem, all Unixes solved it long time ago.
You may want to check the technical merits before recommending the project for adoption.
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.
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.
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.
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.
They also combine in an obvious way. If you mount another filesystem somewhere, it's contained in that somewhere, not mixed in with the existing one in some unexpected complex way.
They're not a natural fit for real world data, but there's a tradeoff between serving humans and serving nature.
I'd argue they only seem that way because we've been raised and taught to use them but haven't been taught sufficiently to think about other ways to organize knowledge.
> They're not a natural fit for real world data
In "A City is not a Tree"[1], Christopher Alexander discusses the semilattice in relation to city planning and human societies. Clay Shirky has previously noted[2] that categories and ontologies are too brittle to serve human thinking.
As an example of an ongoing attempt to create a hierarchical ontology that isn't helpful, look at any list of music genres. Also note that social networks are not organized hierarchically – humans have the ability to handle interconnected structures just fine.
This also relates to why many people don't understand or can't quite relate to true distributed peer-to-peer computing or systems where there is no central controller or fail to grasp emergent behavior. But nature is fine with completely decentralized systems: see, for example, foraging ants. See, for example, Emergence: The Connected Lives of Ants, Brains, Cities, and Software by Steven Johnson
1. https://blogs.ischool.berkeley.edu/i103su12/files/2011/07/19... 2. https://oc.ac.ge/file.php/16/_1_Shirky_2005_Ontology_is_Over...
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.
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.
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.
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.
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?!
Yes, why would anyone need better search or a faster, easier to organise file system? I can't think why.
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.
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
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)
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.
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
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!
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.
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.
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.)
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.
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.
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.
... 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.
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.
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.
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?
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 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.
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 ?
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
And I can rip `find -name` through a 4TB SSD pretty quickly. Usually only a subset is required, because I remember roughly where it is.
For my NAS I spend a bit of time on keeping files organized.
I don't generally want full-text search either, it tends to be cluttered with crap and I don't use full-text indexers (invariably they seem to decide to reindex whenever I least want them to).
How are safe-saves handled in Didgets? That's usually a case where a unique file-ID gets changed.
(Is "safe-save" the canonical name for this? Or atomic-save maybe? Where you save to a new filename, then move that file into place.)
I would expect that a similar operation would be supported.
https://en.wikipedia.org/wiki/Be_File_System
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/
But the last serious shot at this was recent enough and a big enough disaster (Longhorn's WinFS), and/or a few years into iPad ownership when people started wanting to use it as a more serious computing device with an awkward few years until it got "file management" (it always had an FS). Both are too recent. Try again in another 10 years.
> If you have ever forgotten where you stored a file in a file system Nope, never happened to me.
> File systems let you store any file in any folder, regardless of whether the folder path is appropriate for the file YES, exactly, that is a feature, not a problem. If it is not appropriate for the file, you only have yourself to blame for putting it there in the first place.
> Even if you remember some parts of the file name > searching by file extension may or may not turn up the file you were looking for Who searches for file by name? Names mean nothing. You find the file by navigating down the relevant hierarchy based on what you are looking for. By file type, are you kidding me?
A hierarchical file system is ideal as the basis of file organization. Tags and search can be added on top of that (and admittedly have room for improvement) if you really struggle to handle organizing your files by yourself (or some unstated use case the OP has in mind).
I'm struggling to figure out how the OP operates... at some level they seem like a computer illiterate person who saves everything to the desktop then struggles to find stuff. But, I'm sure that is not actually the case... so do they just fail at making an attempt to organize? I'd be interested to better understand what type of files they have so many of that they have to resort to constantly searching by file name or type and need a faster way to do that.
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.
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.