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?

link|improve this question
feedback

2 Answers

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.

link|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 (git.kernel.org/?p=linux/kernel/git/next/linux-next.git;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
feedback

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.

link|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
feedback

Your Answer

 
or
required, but never shown

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