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.
The HP (HP-UX) man page for mount(2) says:
If mount() fails, errno is set to one of the following values.
[EACCES] A component of the path prefix denies search permission.[EBUSY] path is currently mounted on, is someone's current working directory, or is otherwise busy.[EBUSY] The file system associated with fs is currently mounted.
You get the first EBUSY when your question (1) applies because:
- if the directory is already a mount point, you lose access to the previously mounted directory, which makes the prior mount irrelevant.
- if the directory (say
/some/where) is some process's current directory, you have a process with a different view of the contents of /some/where; newcomers see what's on the mounted file system, but the old processes see what was in the mounted-upon directory.
You get the second EBUSY to answer your question (2) when the file system is already mounted - in other words, you can't mount it twice. This is a good thing - there would be a dreadful danger of confusion if two separate mount points both went around assuming they had exclusive access to the superblock etc when it was in fact shared. It would also be confusing if creating a file /some/where/newfile also simultaneously created /opt/other/newfile because the same device was mounted on both /some/where and /opt/other.
I haven't checked the AIX, Solaris, Linux, MacOS X, BSD man pages for mount(2), but I expect the behaviour to be the same.
Best Answer
There is this POSIX definition :
This definition is repeated with different phrasings in the POSIX descriptions of all file-commands.
For example for rmdir :
This above convoluted definition for an Empty Directory is apparently behind this funny convention, and its purpose is to avoid any exceptions to the rule, not even for slash (/).