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