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
