On 2022-10-13 00:48, Rick Moen wrote:

fixes that.)  This error mode is analogous to the "dangling 

symlink" problem that teaches all sysadmins "don't use a symlink unless a hard link cannot do the job".

Ah yes, ... symlinks / symbolic links.

Hard links or bust! ;-) And yeah, rather literally true - at least in many ways. Rather a whole 'nother topic, and I wouldn't quite go as far as to say symlinks=bad, they do however tend to get overused. And effectively, for the most part, symlinks only offer one significant "solution"/advantage over hard links ... but with that they bring also a whole lot of problems, risks, and general breakage. That's not that hardlinks are entirely without risk, but there's a whole lot of problems one can get from symlinks, that one will never have to worry about with hardlinks. And yes, chief among them, the dangling symlink issue(/plague).

So, *much* of the time, hard links are better. A key advantage, there will never be a "dangling symlink" issue with a hard link. A dangling symlink being case where symlink refers to a path that no longer has anything there. Basically the target is moved or removed and ... the source has no clue about it. Rather like web pages and 404 page not found errors. In very much the same way, they're broken links.

So, what's the /one/ significant useful thing that symbolic links can do that hard links can't? Yes, they can cross filesystems - notably refer to something on a different filesystem - just can't do that with hardlinks ... though, even with hardlinks, there can be ways to address that, e.g. have one more copy on that other filesystem. Or also mount it to that other filesystem ... e.g. Linux even lets you mount a file of type ordinary file from one filesystem atop same on another filesystem (bind mounts). Or, you could not have them on separate filesystems - but use the same filesystem. Could even have something periodically check, and update copy if/when needed/relevant. Anyway, there are alternatives to symlinks for dealing with that issue - those are at least some of the possibilities.

Hardlink "hazards"? Not much. The key thing to be aware of with file having multiple hard links is, it's one file - all the same file. The (hard) links are just the names by which the file is known in the directory(/ies) on the filesystem where it's present.

So ... when/where does it get more, uh, "interesting", complex, and/or messy?

Let's start with symlinks. They can be relative, or absolute. "Of course" if the target is removed, the source symlink becomes a dangling link - no surprises there. But moves get more interesting. If one uses relative symbolic links, and sources and targets are likewise moved in same relative manner under same location in the filesystem hierarchy, they continue to work and point to the same existing now moved targets. But if absolute symlinks were used (target starts with / in the link), then they break. However, if the source symlinks are moved, but the targets don't move, if the symlinks are absolute they continue to point to the same (unmoved) targets - but if the symlinks are relative (don't start with /) then they break. Also, under chroot, relative symlinks will contiue to work if the chroot point is a common ancestor in the hierarchy relative to both source and target. If that's not the case or they're absolute, they break. So ... no guarantees things won't break, but some careful thought and planning regarding use of symbolic links, and relative vs. absolute, and exactly what one does and doesn't move and how, well, ... can at least reduce breakage with due planning and attention.

And ... lovely thing about hard links - can move any of those anywhere within the same filesystem, and there's absolutely no breakage of the link relationship ... as they're all still links to the same file - no matter where those links are on the filesystem or how they're named on the filesystem. But yes, "of course", can't do a hard link across/between separate filesystems. Though as mentioned, there are often ways to work around that if/when one really needs to ... and besides using a symbolic link. And, yeah, seems to me the more "territory" a symbolic link traverses (further apart in hierarchy and/or across filesystems), the more probable it is to break / get broken. Most notably when (re)moving the target, the more distant from the source, the more probable it is source will be forgotten and things broken. Whereas, $ ln -s foo bar When poking around in that directory and considering (re)moving the target, one is more probable to actually notice and consider the symlink and it's relationship to the target. Not foolproof, but ... somewhat more goof resistant?

Now, let's look at some more interesting bits. Let's say you have a super actively referenced critical configuration file. For sake of argument, let's say it's: /etc/critical And ... you need to change its configuration. Let's also say it's at least somewhat large ... more than one filesystem physical block, maybe even hundreds or thousands or more. So, if you have lots of stuff reading it essentially continuously, how do you safely update it? # vi /etc/critical Surely you jest. May vary by editor, but most typical editors will, when writing out the file, overwrite the original. Well, *nix, multi-user multi-tasking operating system, so, while that file is being overwritten, stuff can read it. So, something may read it, while it's been partially overwritten and, e.g. get start of the new data, then EOF before getting it all. Not good for our /etc/critical file and the host. So, one of the relatively generic ways of safely doing that is instead, in same directory (or at least same filesystem) a new file is created, with same ownerships and permissions. Then after that file is fully written out, the new file replaces old via the rename(2) system call - which is (at least on ordinary local filesystem types) guaranteed to be atomic. Anything that opens /etc/critical to read it will either get the old file and its contents, or the complete new file and its contents. There's never a between, the /etc/critical path is always there, is always one of those two files, and in chronological sequence - no jumping back and forth - once the newer file is placed there, that's what that path gives, before that, the old file, at no point does the path fail nor will it at all open to the older file again after the rename(2) has completed - that's it - nice simple fast clean switch from old to new? Right? Mostly. ("Of course", also, anything that still has the old file open still gets the old data - until it (typically closes it and) reopens it - and generally using same path again. But most anything that critically cares about changes to data on that pathname will generally quickly notice change (e.g. inode data on old file changes), and will then generally promptly reopen by pathname. Some daemons/services might need to be explicitly told to reopen the "file" (pathname, to get the new file and data)).

Now let's modify that scenario slightly. Let's say that for, e.g. reasons of compatibility, /etc/crit is equivalent and should have same contents, and some programs use /etc/critical, and some use /etc/crit. So, let's say /etc/critical and /etc/crit are hard links to the same file. If one invokes an editor, or uses other means that overwrite the file ... there's the issue of things reading the file while that's taking place, that may get a bad read of that data - something that's neither the old, nor new config - not so great. However, once that write has completed, both links have same data - and at same time - as it's only one file, just two (hard) links. Okay, what if instead, we go the rename(2) way (e.g. as mv(1) will to in the more simple cases). We can replace one of the two hard links with the new, then likewise replace the other link with a second hard link to the new. But there may be an issue with that. What if we need both to be updated at the exact same time - and as an atomic operation - so we never have the two paths being something that could be opened at same exact time giving different data results. Well, two separate rename(2) operations won't suffice, as various processes can open and read things between those two rename(2) operations. So, how to "fix" that and avoid both problems - race condition issues with overwriting file, and race condition issues with separately replacing two pathnames? Here the solution is ... uhm, yeah, ... a symbolic link. Of the two paths, have one be a symlink to the other. Now we leave the symlink alone, and use rename(2) to replace the other - which is of type ordinary file. Now the update happens atomically in most regards effectively for both paths. The operating system still has to read the link from the symlink, and open the path that it refers to, but once it at least gets to that point - so if it's already made it at least that far, then either via the symlink, or the direct path, the same - either older, or replaced with newer - file will be opened and read.

So, symlinks aren't /all/ bad, but they should be carefully and judiciously used (and not overused). And many of such timings aren't /nearly/ that critical ... sure, ought do atomic updates to be safe, but much of the time sysadmins fail to do that where they ought, and for the most part it (almost) never breaks things ... though some files /are/ significantly more critical, and failing to do it properly can (and certainly sometimes does) break things if not properly replaced/updated (e.g. do an overwrite of a critical library or binary and the host can about instantly be seriously hosed ... package management software takes care of those details on replacement to avoid such problems).

So ... directly overwite the file - generally not atomic and may get some reads of bad data before overwrite is complete. Replace the file via rename(2) - generally better - but you lose linking relationship to any additional hard links. Replace those separately with additional rename(2) operations and one loses the synchronicity (both paths won't be updated at exact same time). Have one hard link to ordinary file, any others requiring simultaneity and being atomic on its update be symbolic links to that path - that's about as good as it gets in that scenario ... but most scenarios don't have requirements that stringent, so most of the time there are better simpler solutions.

Though far from universal, some files that need updating and may be rather to highly critical, have their own locking mechanisms and protocols for dealing with these types of matters. E.g. for passwd(5), there's vipw, mail files generally have their own locking protocols, visudo(8) uses locking protocols on the sudoers(5) files, etc. But not everything has its own specific locking protocol - so one shouldn't presume too much.