rsync --delete with empty source folder for fast snapshot deletion: Permissions of hardlinked files are changed to 644. Workaround?

[rsync at altfeld-im.de]

On Fri, 2023-09-22 at 07:37 -0400, Kevin Korb wrote:
> So I decided to do a quick test using the Linux kernel source tree since 
> it has lots of files.

Excellent idea using kernel sources! A lot of different files...
I will use this to create indicative benchmarks for different scenarios...

>   I duplicated a tree, used 'find . -type f -exec 
> chmod 444 {} +' to make read only files for rsync to want to chmod, then 
> used cp -al to make several duplicate trees using hard linked files.
> [...]
> But also, I did not experience the problem you are describing.  My surviving 
> hard links in the duplicate trees were still 444.

If attached a script that does the same (with one file instead of the kernel source tree)
but in my case 444 became 644 again.

- Q: Which rsync version, distro and file system do you use?

- Q: Does my attached script reproduce the permission change?

- Q: Did my script attached to the initial post here reproduce the permission change?



PS: In my case the attached script shows (excerpt):

./setup_cp_al.sh

Tested with
- rsync  version 3.2.7  protocol version 31
- ext4 file system
- Ubuntu 22.04

File stats BEFORE rsync --delete:

  File: snapshot2/read_only.txt
  Size: 0         	Blocks: 0          IO Block: 4096   regular empty file
Device: 10305h/66309d	Inode: 17571021    Links: 3
Access: (0444/-r--r--r--)  Uid: ( 1000/ user1)   Gid: ( 1000/ user1)
Access: 2023-09-22 20:51:16.690961150 +0200
Modify: 2023-09-22 20:51:16.690961150 +0200
Change: 2023-09-22 20:51:16.694961109 +0200
 Birth: 2023-09-22 20:51:16.690961150 +0200

File stats AFTER rsync --delete

  File: snapshot2/read_only.txt
  Size: 0         	Blocks: 0          IO Block: 4096   regular empty file
Device: 10305h/66309d	Inode: 17571021    Links: 2
Access: (0644/-rw-r--r--)  Uid: ( 1000/ user1)   Gid: ( 1000/ user1)
Access: 2023-09-22 20:51:16.690961150 +0200
Modify: 2023-09-22 20:51:16.690961150 +0200
Change: 2023-09-22 20:51:16.694961109 +0200
 Birth: 2023-09-22 20:51:16.690961150 +0200

Results (after deleting snapshot1 via rsync --delete):
1. The 'Change' time of the hardlinked file was updated
2. The hardlinked file has now different access rights (644 instead of 444 so it is writable again!)
This does NOT happen if 'rm -f snapshot1/' is used!