Here is the missing attachment ;-)
On Fri, 2023-09-22 at 21:01 +0200, rsync--- via rsync wrote:
> 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!
>
>
setup_cp_al.sh
Description: application/shellscript
-- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
