4 ms·

Hard links are not too bad of idea as long as they are done on files though they do have some downsides. There are some very good reasons why hardlinks on direc

by buzer 4y ago

Hard links are not too bad of idea as long as they are done on files though they do have some downsides. There are some very good reasons why hardlinks on directories are not easy to enable. If something is scanning things recursively, they would end up in infinite loop if they are not keeping track of (disk,inode) tuples for parent directories, especially if they follow symlinks. IIRC they are explicitly disallowed in Linux, you would need to modify kernel source to allow them. I have no clue why they are saying that they are hard linking directories, I sure hope they are only doing it on file level.

jeroenhd 4y ago
I've caused infinite scanning bugs to appear on accident with just soft links, though. I know soft links and hard links are processed differently at the lowest levels of the I/O stack, but I think there are few languages and run times where that's actually the default. In most programming languages I've used on Linux, symlink expansion is on by default, creating all the problems you can think of. Yes, you can use whatever API call readlink relies on to prevent loops, but you can also keep a set of inode numbers on a file system and stop processing on duplicates. In both cases you need to do all kinds of workarounds. The best argument I've heard is that hard linked directories break the acyclic graph property of the file system but even there I'm not so sure if that's really a problem in an environment where most tools recurse into soft links anyway. I suppose the C folks that like to do all the hard things themselves would get annoyed by having to add another check? I don't think the kernel forbids directory hard links per se; NTFS has junction points which are somewhere between hard links and soft links for directories, and NTFS support made it into Linux. I don't know how the kernel exposes directory junctions in Linux, but they're different from soft links (in that they'll be processed in the server for SMB file servers, as opposed to symlinks which are resolved on the client).

by buzer 4y ago

jeroenhd 4y ago

I've caused infinite scanning bugs to appear on accident with just soft links, though. I know soft links and hard links are processed differently at the lowest levels of the I/O stack, but I think there are few languages and run times where that's actually the default. In most programming languages I've used on Linux, symlink expansion is on by default, creating all the problems you can think of. Yes, you can use whatever API call readlink relies on to prevent loops, but you can also keep a set of inode numbers on a file system and stop processing on duplicates. In both cases you need to do all kinds of workarounds. The best argument I've heard is that hard linked directories break the acyclic graph property of the file system but even there I'm not so sure if that's really a problem in an environment where most tools recurse into soft links anyway. I suppose the C folks that like to do all the hard things themselves would get annoyed by having to add another check? I don't think the kernel forbids directory hard links per se; NTFS has junction points which are somewhere between hard links and soft links for directories, and NTFS support made it into Linux. I don't know how the kernel exposes directory junctions in Linux, but they're different from soft links (in that they'll be processed in the server for SMB file servers, as opposed to symlinks which are resolved on the client).