GCFS: a Garbage-Collected Filesystem for Linux
madore.org
madore.org
For example, there would be no need in archivers (like tar), when you could do `cp ./directory archive.tar` (OS X has something similar this with dmg HFS images). Or you could have `/etc/foo.config` as a text file, but also access separate options as `/etc/foo.config/section/option`. Or you could have versioning built-in into a filesystem. `./foo.txt` is a current version, `./foo.txt/history/` is a directory with a list of revisions, and `./foo.txt/history/2010-01-23T16:24:00Z.001` is an old version snapshot.
This lead to lots of weird things being implemented (like a reboot-persistent ram-drive), but one of the things I remember distinctly is the tar-example you mentioned (except it was lzh/lha). You would literally do cd myArchive.lha and that was it. This was a legitimate file-system path where you could do whatever you wanted. Operations may have been slow on bigger archives, but you could treat it as just another directory. It was very neat.
I've always missed having that feature in sub-sequent OSes I've used and I'm very disappointed it's been 10 years and seemingly the best we have these days is Windows Explorer's Zip-support.
This is why filesystems should be connected to some central place (in GNU/Linux that's the kernel VFS switch).
Do you recall any of these offhand? Thanks.
While I was writting the comment above I was mostly thinking of Plan 9 and GNU Hurd. Couldn't quickly remember exact names, but you should look in direction of those two OSes. They were made to address the shortcomings in UNIX design, and had some fancy concepts.
ZFS makes you take snapshots regularly and then lets you look at the state of the file at a given snapshot.
I am using the snapshot feature in BtrFS for 6 months now. Love it.
Look at the current state of FUSE-based archiver filesystems. They use kludges like file ./archive.tar.gz but (AVFS example) directory ./archive.tar.gz#/file.txt to get around this limitation.
As for Windows Registry - it is not an absolute evil, it's just that Windows implementation of the idea of a centralized tree-like key-value configuration storage is unbelievably crappy. For example, there're (Plan 9-inspired) /proc and /sys, and they feel perfectly fine.
That said, I'm far from convinced allowing cycles in a directory structure would actually be useful for anything.
Of course you can already do that easily enough with /tmp, but /tmp has its own problems: if it is shared between all users then it is a well-known source of security problems, and if your OS has private /tmp then that has its own problems too (ie. it's not shared between users of the same application). The other problem with /tmp is that it isn't "garbage collected" very quickly -- on my Fedora server, unreferenced /tmp files stay around for up to 10 days.
With GCFS it looks like you could get rid of /tmp altogether. Applications could just create a directory anywhere (eg. some random name under $HOME) and then "detach" it by removing "..", and then keep it open for as long as they need it, after which time it gets GC'd quickly and automatically.
Technically, apps using temp files are supposed to unlink them after opening them, so that they get cleaned up as soon as they are closed. This is sometimes true of things that are shared, like UNIX sockets, too.
Also, making a file-system not a tree adds a lot of complexity for questionable gains.
$ ln ~ hardlinkdir
ln: /Users/travis: Is a directory
$ ln -s ~ hardlinkdir
$
http://stackoverflow.com/questions/80875/what-is-the-bash-co...
My suspicion is anyone deleting a directory either wants the information within it destroyed or doesn't want to delete the directory after all.
Certainly, more "fuzzy" relations and storage could have their uses - like a downloaded music directory where the least listened songs go away automatically when you need more space. But you would not want to make your entire file system "fuzzy" in the sense that you don't know what's gone and what isn't.
The trashcan/recycle-bin is a great interface for undoing what you thought was the deletion of a file. This, not so much.
But using symlinks means I can't reorganize without great cost, because they don't follow movements around. It also means some of my folders look like shortcuts while some don't, stepping into one causes my path to change wildly (no backing up, usually), and in order to protect my data I have to make sure I never delete (or move) the originals, only the symlinks.
Or say you want to organize your images in two photo applications at the same time - hardlinks mean each can have full control over where they place their file, without interrupting the other, and without duplicating what could be an enormous amount of data.
OSX attempts to solve this with Aliases - essentially, "smart" symlinks that follow changes. If you alias a file and then move the original, the alias will still work. The downside is that essentially no command-line tools handle them in any way, because they're decidedly non-standard. Being able to hardlink folders would allow filesystem organizations not possible before, with safety, tool-compatibility, and efficiency.