I noticed recently while attempting to rsync directories from one drive to 
another that I was getting the familiar "NULL SID", "incorrectly ordered", etc. 
type ownership issues on the destination even though I use noacl for cygdrive 
mounts (I'm aware of the POSIX vs windows ACL issues, etc. hence why I use 
"noacl" for cygdrive). I was able to track down the issue to a specific 
combination of things that creates the problem:

1. I have symlinks in / for each drive pointing to /cygdrive/[a-z] via ln -s 
/cygdrive/<x> /<x>.
2. All symlinks are actually native reparse points as a I run with 
CYGWIN=winsymlinks:nativestrict by default.

Example:

clayne@sv590:/ $ ls -lad /[a-z]
lrwxrwxrwx 1 clayne None 11 Apr 24 12:24 /c -> /cygdrive/c
lrwxrwxrwx 1 clayne None 11 Apr 24 12:24 /e -> /cygdrive/e
lrwxrwxrwx 1 clayne None 11 Apr 24 12:24 /f -> /cygdrive/f
lrwxrwxrwx 1 clayne None 11 Apr 24 12:24 /s -> /cygdrive/s

3. I issue the rsync with something like: rsync -avSHP /f/some-dir/ /s/some-dir/

The issue here is that it appears mount related options such as noacl are 
evaluated differently when native symlinks are used. If I change the 
destination to instead be "/cygdrive/s/dest/dir" then noacl works 
appropriately. On top of all this, if I instead create the /s symlink as a 
"cygwin" style symlink via CYGWIN=winsymlinks things also work correctly - that 
is, the noacl option is used. What I would intuitively expect, atleast within 
the context of acl vs noacl, is for the symlinks to be resolved first and then 
mount options specific to the target resolved based off what the symlink 
actually points to. In the native/nativestrict case, it appears to be doing 
this in reverse and inheriting /'s standard default acl option rather than 
/cygdrive's noacl option.

Footnotes on workarounds:

* I know how to workaround using the root-level symlinks in the first place by 
just mounting cygdrive to /, but I'd have to update various scripts which 
already use /cygdrive and I like having the "windows drives" self-contained 
under /cygdrive (even though I frequently use the / level symlinks as 
shorthand).
* I also know how to avoid the issue entirely by using /cygdrive/<x> for the 
destination but the underlying issue still seems like a bug or an oversight to 
me, particularly given that nativestrict behaves differently when it comes to 
evaluating mount options.
* Another workaround would be to use non-nativestrict symlinks but I want to 
preserve interoperability with native windows applications outside of cygwin 
and I've learned over the years to just avoid anything that isn't nativestrict.

Here's a repro case:

clayne@sv590:~ $ uname -a
CYGWIN_NT-10.0-19045 sv590 3.5.3-1.x86_64 2024-04-03 17:25 UTC x86_64 Cygwin

clayne@sv590:~ $ cat /tmp/link_test 
#!/bin/bash

set -e
set -o pipefail

rm -rf /cygdrive/{f,s}/link_test
mkdir -p /cygdrive/{f,s}/link_test
echo foo > /cygdrive/f/link_test/test

for i in winsymlinks winsymlinks:lnk winsymlinks:sys winsymlinks:nativestrict; 
do
        export CYGWIN="$i"
        link="s_${i//:/_}"
        ln -sfT /cygdrive/s /$link
        rsync -aSH /f/link_test/ "/$link/link_test/$link"/
        ls -la /$link/link_test/$link/test || true
        getfacl /$link/link_test/$link/test || true
done

clayne@sv590:~ $ bash -x /tmp/link_test 
+ set -e
+ set -o pipefail
+ rm -rf /cygdrive/f/link_test /cygdrive/s/link_test
+ mkdir -p /cygdrive/f/link_test /cygdrive/s/link_test
+ echo foo
+ for i in winsymlinks winsymlinks:lnk winsymlinks:sys winsymlinks:nativestrict
+ export CYGWIN=winsymlinks
+ CYGWIN=winsymlinks
+ link=s_winsymlinks
+ ln -sfT /cygdrive/s /s_winsymlinks
+ rsync -aSH /f/link_test/ /s_winsymlinks/link_test/s_winsymlinks/
+ ls -la /s_winsymlinks/link_test/s_winsymlinks/test
-rw-r--r-- 1 clayne None 4 Apr 24 13:38 
/s_winsymlinks/link_test/s_winsymlinks/test
+ getfacl /s_winsymlinks/link_test/s_winsymlinks/test
getfacl: /s_winsymlinks/link_test/s_winsymlinks/test: Not supported

+ true
+ for i in winsymlinks winsymlinks:lnk winsymlinks:sys winsymlinks:nativestrict
+ export CYGWIN=winsymlinks:lnk
+ CYGWIN=winsymlinks:lnk
+ link=s_winsymlinks_lnk
+ ln -sfT /cygdrive/s /s_winsymlinks_lnk
+ rsync -aSH /f/link_test/ /s_winsymlinks_lnk/link_test/s_winsymlinks_lnk/
+ ls -la /s_winsymlinks_lnk/link_test/s_winsymlinks_lnk/test
-rw-r--r-- 1 clayne None 4 Apr 24 13:38 
/s_winsymlinks_lnk/link_test/s_winsymlinks_lnk/test
+ getfacl /s_winsymlinks_lnk/link_test/s_winsymlinks_lnk/test
getfacl: /s_winsymlinks_lnk/link_test/s_winsymlinks_lnk/test: Not supported

+ true
+ for i in winsymlinks winsymlinks:lnk winsymlinks:sys winsymlinks:nativestrict
+ export CYGWIN=winsymlinks:sys
+ CYGWIN=winsymlinks:sys
+ link=s_winsymlinks_sys
+ ln -sfT /cygdrive/s /s_winsymlinks_sys
+ rsync -aSH /f/link_test/ /s_winsymlinks_sys/link_test/s_winsymlinks_sys/
+ ls -la /s_winsymlinks_sys/link_test/s_winsymlinks_sys/test
-rw-r--r-- 1 clayne None 4 Apr 24 13:38 
/s_winsymlinks_sys/link_test/s_winsymlinks_sys/test
+ getfacl /s_winsymlinks_sys/link_test/s_winsymlinks_sys/test
getfacl: /s_winsymlinks_sys/link_test/s_winsymlinks_sys/test: Not supported

+ true
+ for i in winsymlinks winsymlinks:lnk winsymlinks:sys winsymlinks:nativestrict
+ export CYGWIN=winsymlinks:nativestrict
+ CYGWIN=winsymlinks:nativestrict
+ link=s_winsymlinks_nativestrict
+ ln -sfT /cygdrive/s /s_winsymlinks_nativestrict
+ rsync -aSH /f/link_test/ 
/s_winsymlinks_nativestrict/link_test/s_winsymlinks_nativestrict/
+ ls -la /s_winsymlinks_nativestrict/link_test/s_winsymlinks_nativestrict/test
-rwxrwx---+ 1 clayne None 4 Apr 24 13:38 
/s_winsymlinks_nativestrict/link_test/s_winsymlinks_nativestrict/test
+ getfacl /s_winsymlinks_nativestrict/link_test/s_winsymlinks_nativestrict/test
# file: /s_winsymlinks_nativestrict/link_test/s_winsymlinks_nativestrict/test
# owner: clayne
# group: None
user::rwx
group::r-x
group:Authenticated Users:rwx
group:SYSTEM:rwx
group:Administrators:rwx
group:Users:r-x
mask::rwx
other::---

I obviously can't include explorer screencaps, but suffice to say, 
"winsymlinks:nativestrict" is the only one that ends up with NULL SID, 
incorrect order, etc issues on the synced files.

-cl


-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple

Reply via email to