Describe the bug
While rsync hardlinks unchanged files with the previous snapshot, local hardlinks on the system appear to be lost.
This causes a significant amount of space to be wasted and could potentially result in some users being unable to restore past backups if they don't have enough space for the now duplicate files. It could also risk breaking programs that had expected to be working with hardlinked files. Finally when the user runs commands that create new directories containing thousands of hard linked files such as flatpak repair, timeshift will waste a lot of space and take significantly longer to back up as it's creating unnecessary new files.
To Reproduce
Steps to reproduce the behaviour:
- Create a file on the local system
- Create a hard link to that file
- Make an rsync snapshot
- Run
ls -i on the copy of both files within the snapshot
Expected behaviour
Both files in the snapshot should have the same inode number as they were originally hardlinked.
Observed behaviour
Both files instead have unique inode numbers.
Screenshots


System:
- Linux Distribution Name and Version: Kubuntu 25.10
- Desktop: KDE
- Timeshift Version: 24.06.6
- Timeshift Mode [btrfs/rsync?]: rsync
- Display Server: wayland
Describe the bug
While rsync hardlinks unchanged files with the previous snapshot, local hardlinks on the system appear to be lost.
This causes a significant amount of space to be wasted and could potentially result in some users being unable to restore past backups if they don't have enough space for the now duplicate files. It could also risk breaking programs that had expected to be working with hardlinked files. Finally when the user runs commands that create new directories containing thousands of hard linked files such as
flatpak repair, timeshift will waste a lot of space and take significantly longer to back up as it's creating unnecessary new files.To Reproduce
Steps to reproduce the behaviour:
ls -ion the copy of both files within the snapshotExpected behaviour
Both files in the snapshot should have the same inode number as they were originally hardlinked.
Observed behaviour
Both files instead have unique inode numbers.
Screenshots


System: