[speed_spread]

IMO hard links are underused in filesystems. You can have the same file / dir appear in different places under different names. Once linked, app doesn't have to care and runtime cost is zero.

[PhilipRoman]

Hard links suffer from the general issue of there being two styles of writing to a file - open(2)/write(2) vs rename(2). Depending on the internals of each program you use to update the file, you will get very different results.

This is one of the ugliest parts of POSIX design, making idioms like -o /dev/null and file attributes unpredictable (I've had a server run out of disk space because a root-owned process used rename-style writing on /dev/null)

[lstodd]

That was breakdown on a different level: your server process had no business of renaming stuff and it still did that. POSIX had nothing to do with this.

[PhilipRoman]

I'd agree if POSIX provided something like an open() flag which made the changes visible atomically, but as it stands, the rename() idiom is the mainstream way of durable file writing, so it is commonly used. Practical example using busybox sed: (GNU sed detects this case and refuses to overwrite)

  / # stat /dev/null
    File: /dev/null
    Size: 0          Blocks: 0          IO Block: 4096   character special file
    ...
  / # sed -i 's/foo/bar/' /dev/null
  / # stat /dev/null
    File: /dev/null
    Size: 0          Blocks: 0          IO Block: 4096   regular empty file
    ...

[jmalicki]

It's the fundamental idiom of how to do atomic file replacement. The sever process had better be doing that over editing a text file in a way that could leave it invalid if the process OOMs mid edit, or another process is reading it while it's being written.