Cygwin rsync changes (acl) permissions, even when not asked to?

Brian Inglis brian.inglis@systematicsw.ab.ca
Fri Jan 24 16:31:29 GMT 2025


On 2025-01-24 08:36, Brian Inglis via Cygwin wrote:
> On 2025-01-24 02:23, Marco Atzeri via Cygwin wrote:
>> On 24/01/2025 09:32, Mario Emmenlauer via Cygwin wrote:
>>> There is an an issue that plagues me when using git in Cygwin.
>>> I have two developer machines, one with Linux, and one with Windows. On
>>> the Windows machine, when I clone sources with git, everything works well.
>>> However, when I then use rsync to copy changes from the Linux machine to
>>> Windows, the file permissions change on all files! In turn, git complains
>>> about a new executable permission. And chmod fails to restore the previous
>>> state.

Sounds like *rsync* is adding default Windows permissions with +x!

>>> Currently, the only way I found to restore a useful state, is to remove
>>> the whole directory, and clone again from git!
>>> Here are the details:
>>> I'm using rsync options --verbose --recursive --delete which in my eyes
>>> should not modify permissions. I clone with rsync over the already existing,
>>> unchanged files from git, so there should be anyways no need for rsync to
>>> re-transfer or modify the files.

> Why clone a git repo with rsync when you can just use git from Linux to Windows?

>>> The directory in question is a subfolder on the C: drive, which is an
>>> NTFS-formatted NVMe. I created the parent folder as a normal user, and did
>>> not apply any special permissions. In fstab, I leave default Cygwin options.

> Created parent and subfolder as a normal Windows or Cygwin user?
To clarify:
Did you create the parent and subfolder as a normal Windows user or as a normal 
Cygwin user?

>>> rsync is version 3.3.0, Cygwin is version 3.5.5-1.

> Are you sure you are running...
Sorry --
Are you sure you are running *Cygwin* rsync - test with `which rsync`, and it is 
best to copy and past the command lines and outputs directly, for example:

$ uname -srvmo
CYGWIN_NT-10.0-19045 3.5.5-1.x86_64 2024-12-20 16:19 UTC x86_64 Cygwin
$ head /proc/version
CYGWIN_NT-10.0-19045 version 3.5.5-1.x86_64 (runneradmin@fv-az1347-815) (gcc 
version 12.4.0 (GCC) ) 2024-12-20 16:19 UTC
$ which rsync
/usr/bin/rsync
$ rsync --version
rsync  version 3.3.0  protocol version 31
Copyright (C) 1996-2024 by Andrew Tridgell, Wayne Davison, and others.
Web site: https://rsync.samba.org/
Capabilities:
     64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
     socketpairs, symlinks, symtimes, hardlinks, no hardlink-specials,
     hardlink-symlinks, IPv6, atimes, batchfiles, inplace, append, ACLs,
     xattrs, optional secluded-args, iconv, prealloc, stop-at, crtimes
Optimizations:
     no SIMD-roll, no asm-roll, openssl-crypto, no asm-MD5
Checksum list:
     xxh128 xxh3 xxh64 (xxhash) md5 md4 sha1 none
Compress list:
     zstd lz4 zlibx zlib none
Daemon auth list:
     sha512 sha256 sha1 md5 md4

rsync comes with ABSOLUTELY NO WARRANTY.  This is free software, and you
are welcome to redistribute it under certain conditions.  See the GNU
General Public Licence for details.

>>>  From acl checks, it seems that rsync would modify only one of the ACLs.
>>> The second ACL before is "COMPANY\User:(R,W,D,WDAC,WO)", and after running
>>> rsync is "COMPANY\User:(F)". I'm not sure what this means, but even less
>>> I understand why rsync performs this change?
> 
>> where is located this directory ?

> Also what are the parent and subfolder directory paths and ACLs, particularly 
> DACLs, from getfacl and icacls?

>> Can you provide the cygcheck.out as attachement ?
>> see https://cygwin.com/problems.html

> I have had some success fixing Cygwin ACLs, messed up by Windows programs, using 
> setfacl -b on directories and files, but I sometimes have to fix up directory 
> DACLs using setfacl, then fix up the file ACLs, then permissions.

*NOTE:* current Cygwin *rsync* version has *6 CVEs* against it, and current 
Cygwin *git* version has *2 CVEs* against it, so they need updated soon before 
being used outside firewalls!

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retrancher  but when there is no more to cut
                                 -- Antoine de Saint-Exupéry


More information about the Cygwin mailing list