> The idea behind NHFS is to enhance usability of the file system for basic file management tasks by allowing the same document to be categorized multiple times, without using impractical band-aid solutions, such as symbolic links.
1. How are symbolic links impractical?
2. You can already do what the OP says above right now without any FUSE nonsense. It's called a hard link. Hard links have been around for ages. It's just that people don't like using them liberally like the OP describes.
This just feels like a bad idea to me. If I want to delete the file permanently, I can use the symbolic links to it to figure out where it "really" is and delete it there. Unless the OP thinks that deleting it one place should delete it everywhere, which behavior would be difficult to place permissions around, especially in a Unix context (but definitely in a Windows context, where permissions can be inherited from parent folders). With hard links, deleting all links are required.
I don't really see a use case for this. I just see it complicating file system management.
The single advantage of what this could do for you is easier (faster) access to all the hardlinks a given file may have; in current file systems like ext4 there's no way of getting to all hardlinks short of searching the entire drive if I'm not mistaken.
Other than that, I see little in the way of a value proposition of this over existing file systems. There's relatively little what you can and will do with hardlinks anyway; two things I can think of is (1) making backups the MacOs timemachine way with hardlinks for all files that have remained untouched since the most recent backup session, and (2) maintaining a 'physical clone' of configuration file in a more convenient location (that can then be backuped without producing dangling symlinks).
Other than that, symlinks are IMHO preferable over hardlinks because symlinks are (1) actually less brittle than hardlinks when copying (archivers will store symlinks, and, done properly, they will remain being symlinks and spring back to life when restored to an appropriate environment, or can be rewritten in the bulk when sources and/or targets have been moved relatively to each other). With hardlinks, you'll have to very careful to maintain the single-storage-with-two-entries semantics.
(2)ndly, symlinks are systematically preferrable over hardlinks because they can (2a) point to any mounted location and (2b) allow to produce a two-tiered structure where the primary structure stays a tree without surprising identities between far-flung identities between /that/file/i/thought/was/unique.txt and /that/other/file/that/accidentally/changed/for/no/obvious/reason.txt ("spooky action at a distance" which even the universe deems too difficult to bother about). The existence of symlinks documents that "the secondary location (name, path) for the given file is here, while its primary location is elsewhere. Hardlinks won't give you that.
I've never heard of tools that when given two distinct locations in two distinct snapshot sessions will be able to re-build the shared hardlink semantics of the original situation of your disk. One way to achieve this could be to use a content-addressed FS and have a bit on each file entry that states whether the entry is meant to be copy-on-write (COW), i.e. an independent copy or not, when it is treated as a 'lockstepped' clone. That might turn out to be as brittle as it sounds, though.
6 comments
[ 2.4 ms ] story [ 21.2 ms ] threadSeems like a bit of anti-pattern.
1. How are symbolic links impractical?
2. You can already do what the OP says above right now without any FUSE nonsense. It's called a hard link. Hard links have been around for ages. It's just that people don't like using them liberally like the OP describes.
This just feels like a bad idea to me. If I want to delete the file permanently, I can use the symbolic links to it to figure out where it "really" is and delete it there. Unless the OP thinks that deleting it one place should delete it everywhere, which behavior would be difficult to place permissions around, especially in a Unix context (but definitely in a Windows context, where permissions can be inherited from parent folders). With hard links, deleting all links are required.
I don't really see a use case for this. I just see it complicating file system management.
Other than that, I see little in the way of a value proposition of this over existing file systems. There's relatively little what you can and will do with hardlinks anyway; two things I can think of is (1) making backups the MacOs timemachine way with hardlinks for all files that have remained untouched since the most recent backup session, and (2) maintaining a 'physical clone' of configuration file in a more convenient location (that can then be backuped without producing dangling symlinks).
Other than that, symlinks are IMHO preferable over hardlinks because symlinks are (1) actually less brittle than hardlinks when copying (archivers will store symlinks, and, done properly, they will remain being symlinks and spring back to life when restored to an appropriate environment, or can be rewritten in the bulk when sources and/or targets have been moved relatively to each other). With hardlinks, you'll have to very careful to maintain the single-storage-with-two-entries semantics.
(2)ndly, symlinks are systematically preferrable over hardlinks because they can (2a) point to any mounted location and (2b) allow to produce a two-tiered structure where the primary structure stays a tree without surprising identities between far-flung identities between /that/file/i/thought/was/unique.txt and /that/other/file/that/accidentally/changed/for/no/obvious/reason.txt ("spooky action at a distance" which even the universe deems too difficult to bother about). The existence of symlinks documents that "the secondary location (name, path) for the given file is here, while its primary location is elsewhere. Hardlinks won't give you that.
I've never heard of tools that when given two distinct locations in two distinct snapshot sessions will be able to re-build the shared hardlink semantics of the original situation of your disk. One way to achieve this could be to use a content-addressed FS and have a bit on each file entry that states whether the entry is meant to be copy-on-write (COW), i.e. an independent copy or not, when it is treated as a 'lockstepped' clone. That might turn out to be as brittle as it sounds, though.