5 ms·

I'd be curious to know what use case people have today for hardlinks, ever since symlinks became a thing. I've been using Linux for more than 20 years and the

I'd be curious to know what use case people have today for hardlinks, ever since symlinks became a thing. I've been using Linux for more than 20 years and the only case I've found is for rsync incremental backups (--link-dest option), which is great for doing backups to an external USB hard drive and saving space. But that's rather niche.

gunapologist99 5y ago
not so niche. That's a really terrific use for them. Hardlinks are hampered compared to symlinks because they can't be used for directories (which seems just a really silly limitation). It would be awesome to be able to roll up and mirror entire directory trees.
- viraptor 5y ago
  With newer systems this can be often handled at the os level. Both xfs and btrfs support copy-on-write, so you can have the same effect just by doing "cp --reflink".
  - mjevans 5y ago
    Sometimes multiple writable entries for a single object are desirable. As an advanced feature there's plenty of room for abuse and footgun problems, but it's still occasionally, maybe even rarely, the correct tool for the job.
    - caspper69 5y ago
      Why would you just not so this in code? Why require the whole os at the scripting level require this?
    - bodhiandpysics1 5y ago
      What's more important are multiple readable entries for an object! And for those objects not to disapear unless the ref count on them is zero. The quintessential example is a library... By linking it into a directory the program has acccess to, you expose the library to the program. By using a hard link, you protect that library from being erased by another user
  - gunapologist99 5y ago
    Sure, that will do a CoW copy, but it's not actually the same effect at all, is it? In other words, writing to the copy will not propagate the writes to the original. (or am I wrong on that) Besides, won't this walk and copy the entire directory subtree? (i.e., CoW only applied to the files themselves, not just directory entries.) I'm saying I'd like to just have a hard link to the directory itself; if the directory is effectively a list of inode pointers, I just want to add another pointer to that list of pointers. Then, if I create or modify a new file in some deep nested directory in either copy, it will be instantly available in both or more locations without any metadata changes on disk to more than one copy of the metadata itself. This would be interesting for certain use cases.
    - viraptor 5y ago
      I mentioned the CoW in the OP context of reflinks being useful for incremental backups. In that case you do want the "copy will not propagate the writes to the original" behaviour.
- caf 5y ago
  (which seems just a really silly limitation) It's the most straightforward way to ensure the directory structure remains a directed acyclic graph.
singron 5y ago
Reflinks on CoW filesystems are also good for that (along with native features like snapshotting, which are sort of a reflinks of a directory).
anyfoo 5y ago
git uses them for local clones.
eqvinox 5y ago
Standard use case for hardlinks is replacing a file atomically while creating a backup. The steps you do are: 1. create, write, close/sync "file.new" 2. hardlink "file" to "file.old" and sync again 3. rename "file.new" to "file" 4. sync to finish With these steps, regardless of where you are interrupted, you always have a "functioning" copy of the file. This is quite important for tools writing configuration files or state to disk, but also just your plain old office suite preventing total loss of your PhD thesis. (Yes it's not perfect, sync()ing correctly is hard [you need to sync the files and the directory!], and hard filesystem damage/kernel panics can always break things.)

gunapologist99 5y ago

not so niche. That's a really terrific use for them. Hardlinks are hampered compared to symlinks because they can't be used for directories (which seems just a really silly limitation). It would be awesome to be able to roll up and mirror entire directory trees.

viraptor 5y ago
With newer systems this can be often handled at the os level. Both xfs and btrfs support copy-on-write, so you can have the same effect just by doing "cp --reflink".
- mjevans 5y ago
  Sometimes multiple writable entries for a single object are desirable. As an advanced feature there's plenty of room for abuse and footgun problems, but it's still occasionally, maybe even rarely, the correct tool for the job.
  - caspper69 5y ago
    Why would you just not so this in code? Why require the whole os at the scripting level require this?
  - bodhiandpysics1 5y ago
    What's more important are multiple readable entries for an object! And for those objects not to disapear unless the ref count on them is zero. The quintessential example is a library... By linking it into a directory the program has acccess to, you expose the library to the program. By using a hard link, you protect that library from being erased by another user
- gunapologist99 5y ago
  Sure, that will do a CoW copy, but it's not actually the same effect at all, is it? In other words, writing to the copy will not propagate the writes to the original. (or am I wrong on that) Besides, won't this walk and copy the entire directory subtree? (i.e., CoW only applied to the files themselves, not just directory entries.) I'm saying I'd like to just have a hard link to the directory itself; if the directory is effectively a list of inode pointers, I just want to add another pointer to that list of pointers. Then, if I create or modify a new file in some deep nested directory in either copy, it will be instantly available in both or more locations without any metadata changes on disk to more than one copy of the metadata itself. This would be interesting for certain use cases.
  - viraptor 5y ago
    I mentioned the CoW in the OP context of reflinks being useful for incremental backups. In that case you do want the "copy will not propagate the writes to the original" behaviour.
caf 5y ago
(which seems just a really silly limitation) It's the most straightforward way to ensure the directory structure remains a directed acyclic graph.

singron 5y ago

Reflinks on CoW filesystems are also good for that (along with native features like snapshotting, which are sort of a reflinks of a directory).

anyfoo 5y ago

git uses them for local clones.

eqvinox 5y ago

Standard use case for hardlinks is replacing a file atomically while creating a backup. The steps you do are: 1. create, write, close/sync "file.new" 2. hardlink "file" to "file.old" and sync again 3. rename "file.new" to "file" 4. sync to finish With these steps, regardless of where you are interrupted, you always have a "functioning" copy of the file. This is quite important for tools writing configuration files or state to disk, but also just your plain old office suite preventing total loss of your PhD thesis. (Yes it's not perfect, sync()ing correctly is hard [you need to sync the files and the directory!], and hard filesystem damage/kernel panics can always break things.)