On Fri, Dec 05, 2008 at 11:21:22PM -0800, Brad Boyer wrote: > Apple added hard links with osx. Back when I wrote hfsplus originally, > there wasn't any such thing on HFS+ either. The support for the hack > that added the appearance of hard links was added after I stopped > maintaining the code. It's really just a matter of hiding the real > file in a special place and putting stubs with special settings where > all the links appear in the namespace. In all truth both HFS and HFS+ > are inherently incompatible with the very concept of a hard link or > having a file still exist after removal. It's just a horrible hack > that makes it look like it works. Well... That's not too unreasonably way to do them, actually - just treat your hidden directory as real inode table. The tricky part is keeping i_ino stable through all that, but if it's done... FWIW, fs/qnx4 uses a somewhat similar scheme, IIRC. To make things workable you need * hidden directory that would never be reachable by syscalls * recognizable files that would contain references to names in that directory * lookup that would normally lead to such file getting inode of object in hidden directory * link(2) with target being *not* one of those would start with moving target to hidden directory and creating such "link" file in its place. Then it would create a link file in source. That, BTW, would have interesting implications wrt locking - we'd need to modify target's parent, which can get sucky. * unlink(2) with victim dentry not being a "link" file *and* being busy would move the victim to hidden. Otherwise it'd kill the victim outright. * final iput() of file that'd been taken to hidden does deletion of directory entry in hidden if i_nlink is 0. The interesting part is locking - you need to deal with lookup vs. eviction of link(2) target to hidden and with rename vs. the same thing. > > Which is to say, this stuff *must* go. In case of HFS it's obnoxious, > > but not immediately letal. In case of HFS+ it's an instant DoS. > > Feel free. I disavowed any responsibility for this code years ago. And > before anyone thinks of complaining, I'll point out that I wasn't the > one that submitted hfsplus for inclusion in the kernel either. Not blaming you... -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
