For my own purposes, I rely on snapdiff’s default behaviour, which is to skip symlinks. Therefore, I’m actually not sure how well things go in case they are enabled. (Think: circular references.)

It probably doesn’t make sense to resolve symlinks, and count the bytes of the target file. (Also note, the symlink could point to a file outside of the snapshot directory, in which case we certainly don’t want to count these bytes.) But it still might be of interest to see whether a symlink has changed it’s target, or whether it still points to the same file.

I’m wondering whether it’s reasonable enough to include symlinks in the regular file count, without incrementing the byte count, though. So, e.g., a symlink target was changed, increment the “modified” file counter, but not the “modified” byte size.

Otherwise, it might be necessary to introduce a completely separate category or counting logic for symlinks.

(Originally from #2.)

I also haven’t considered hardlinks so far, so their behaviour is not well-defined.

Hardlinks are quite tricky, because their behaviour depends on how the snapshots were created, or whether you compare two snapshots against each other, or whether you compare one snapshot against the original directory tree.

• If you do cp -R for creating a snapshot, then all hardlinks from the original directory tree are created as individual files in the snapshot.
• If you do rsync -r --hard-links for creating a snapshot, then all hardlinks from the original directory tree are cloned (as hardlinks) in the snapshot.

The other issue is that it’s more complex to determine the “redundant” hardlinks within the same snapshot in the first place.

Not sure yet, what the best solution is here. I’m also not sure how common this problem actually is, or whether the additional complexity of solving it is worth the benefit.