Sign up ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

At work, I'm in charge of maintaining the organization of a whole lot of varied data on a standard file-system. Part of this is coming up with sensible classification (by similarity, need, read/write access, etc), but the bigger part is actually documenting it: what documents/files/media should go where, what should not be in this directory, "for something slightly different, see ../../other-dir", etc.

At the moment, I've documented this using a plaintext file readme in every directory I want to document. If someone is unsure what's meant to be in any directory, they read that file.

This works alright, but it seems odd that I have this primitive custom solution to a problem that any maintainer of a non-trivial directory structure must experience. Every company I've known of, for example, has some kind of shared file-system where agreed terminology for categorization is important. In my experience, people just have to learn what's what by trial-and-error and experimentation.

So allow me to propose a better solution, and hopefully you can tell me if it exists. Any directory on any filesystem can have a hidden plaintext file named .readme. Its contents are descriptive human language. It uses some markup like Markdown, with little more than bold, italic, and (relative) hyperlinks to other directories. Now a suitably-enabled file browser will check for a file named .readme whenever it displays a directory. If it exists, its contents are parsed and displayed in an unobtrusive pane near the directory-path widget. Any links therein can be clicked, and the user will be taken to the target directory of that link.

I think that the effort of implementing such a standard would pay back many times over in usability gains. We would have, say, plugins for Nautilus, Konqueror, etc.. It could be used to display directory information in the standard file lists served by webservers. And so on.

So, question: does such a thing exist? If not, why not? Do people think it's a worthwhile idea?

share|improve this question
Since you mention improvements to the file system (or the file browsers for a specific file system), especially for source code, then it's also worth mentioning the much needed feature of file ordering. Most of the file systems have two main types of ordering: alphabetical, and unsorted. But what about a user-specified order? For example in the case of source code, if you have 7 files (classes,modules,components) in a folder (module,package,parent-component), then their "logical" order is usually not the same as the alphabetical order. But rather it is the order of their "dependency tree". – Sorin Postelnicu May 17 at 9:37
So, as standard additions to the modern filesystems, these three features should come by default: 1) file descriptions, 2) custom file ordering inside a folder, and 3) file tagging/labelling. One should not need to use a CMS in order to benefit of these 3 "basic" features. – Sorin Postelnicu May 17 at 9:39

4 Answers 4

As far as I know there is no standard. Here are a few ideas from my experience.

Set it up, never change it

This is were most companies fail. Nothing is worse than an ever changing file-system structure. If it is not possible to keep it constant then a pure file-system is just the wrong container to organize your information. Use a database or a Content Management System.

Use descriptive and consistent directory names

Nobody has the time to read a .filing file or anything else. If your directory names are not self explaining you probably are lost anyway.

Write a documentation for your directory structure

Write a document where you explain the role of every directory. Give lots of examples. Make it available to anyone who has to work with your structure, but don't believe anybody will read it. It should be more like a Bible to you. It's not easy to find an example for such a document, because obviously companies don't publish them. An example from open source software is the Filesystem Hierarchy Standard.

If this sounds a little negative, it is. I've never seen a non-trivial repository based on a file system with more than five users work in the long run in practice. The problem is that whatever categories you'll set up, people will have completely different ideas about them. So to finally answer your questions:

Does such a thing exist?

No, I don't think so.

If not, why not?

In my opinion: For a small static hierarchy with a few users it's overkill. For a large changing hierarchy with many users it won't work because the idea of categories (=directories, folder) doesn't scale.

Do people think it's a worthwhile idea?

Hm, it's an interesting idea. To see if people will use it, someone has to implement it. Instead of a .filing file you could store that information in an alternate data stream (yes, folders can have ADS too). You could use extended attributes on Linux and OSX. The biggest problem would probably be to patch the file browsers.

share|improve this answer
"Nothing is worse than an ever changing file-system structure" except for one that resolutely refuses to change even when the structure not longer makes sense. – eegg May 14 '10 at 12:33
"Use descriptive and consistent directory names" -- absolutely necessary, yes. Unfortunately there's a conflict between descriptivity and brevity -- no-one wants to type a path to a file in /srv/all-hierarchical-data/accessible-only-by-office-and-admin/letters-but-not-p‌​ublic-notices/academic-year-of-2009/... and so on. – eegg May 14 '10 at 12:34
"Write a documentation for your directory structure" -- also a great idea. It's essentially what I'm suggesting; just that the documentation would be distributed rather than monolithic. – eegg May 14 '10 at 12:35
"the idea of categories (=directories, folder) doesn't scale" -- true-ish, except sometimes it just has to. Say, big software source trees (;a=tree). – eegg May 14 '10 at 12:38
"Instead of a .filing file you could store that information in an alternate data stream (yes, folders can have ADS too). You could use extended attributes on Linux and OSX." Possible, I imagine, but decreases the portability and transparency that I think is so important. What if I want to place everything in a git repo? Plaintext files are used for directory-specific config (e.g. htaccess), so why not documentation too? – eegg May 14 '10 at 12:41

Your idea has some merit, but I am afraid that when you need something like this it really means that you need something more structured. I.e. a CMS, maybe just a lightweight one, but definitely something more than just a textual file.

Especially if you want to restrict writing (or even accessing) specific documents (and therefore their containing folders) to some subset of your userbase.

You don't specify your OS, but there are excellent (and free) products like alfresco that could maybe serve you better than your current setup.

share|improve this answer
I've dabbled with various CMSes, but have found that portability, simplicity, and transparency are huge costs to pay when compared to the most venerable CMS out there: the directory tree. Most data I've had to manage could fit into a hierarchy. As a last resort, there are symlinks. And the directory structure is sometimes the only solution: e.g. in software development, the source code is, at base, a directory tree. (Documenting directories like that generally means sticking to a rigid and cryptic schema, which eventually breaks down. I think my solution could help here, too.) – eegg May 14 '10 at 12:01
As I said, your idea has merit, but I do think, like the author of the other poster, that this can't scale beyond a given level. You mention source code, but this is a very specialized case - and when you add code to it you don't look into the existing directories to find where it should "fit". A CMS usually gives you the ability to tag stuff so you have "directories" (folders, spaces, pages) that work like your solution, PLUS a tagging system allowing people to find stuff without having to look for the "right" directory. This is more flexible than symlinks and less prone to errors, IMHO. – p.marino May 15 '10 at 12:23

Here is an idea. Write a script that asks the user various questions about the file and/or do some matching in the file content itself, and then recommends the location to put the file or puts it there itself. The script can be as simple or as complex as you want it to be.

The script acts as a file management system, decision support system, and a living documentation of the filesystem hierarchy. The Linux Filesystem Hierarchy Standard is a bit of a myth if you think about it, because there's a very large variance between distros. However most Linux/Unix users don't actually have to learn about the filesystem hierarchy themselves because various software installed in the system exists that manages the hierarchy in a standardized way (package manager, configuration tool, etc). Various application framework also creates scripts to manage its directories, e.g. django has management commands to create new project, or new app module, or squash migration files, etc.

This has the additional advantage that the script can create various symlinks if the file need to be searched for in more than one way, for instance an index based on the file author or creation date or whatever business rule you have. You can simulate tagging with symlinks. A tag is simple an symlink from a tags directory, so tags/mytag/myfile may be a symlink to actual/myfile.

Additionally it will also be possible to change the filesystem hierarchy structure without changing the user interface.

A filesystem is a database. Not a relational database, but hierarchical database. Think about it like managing a database, you don't really want to require people to have to learn the relational structure, but rather you want the application to present to the user as various tasks they need to do (e.g. are you doing a monthly XYZ report, great, then put it in this folder, and create this symlink, and then you'll need to modify another file to record that you've done the report for this month, etc).

share|improve this answer

wasabi is worth a shot. At your project root, the plain-text source will serve as a solid project overview and you can throw the same document at a browser for some fancier results.

Granted, it's not a filesystem-based solution, but until all the filesystems around support something common, wasabi (or your own implementation of it) could well be the best option.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.