Use RESOLVE_NO_SYMLINKS on Linux when following symlinks is disabled

[gitstashpop]

This addresses a bug where a forward slash is the last element of a symlink directory path and open_dir_nofollow is used.

If a symlink is created to a directory without specifying an absolute path, then the path behind the symlink does not error when opened with open_dir_nofollow.

Take these two symlinks:

> ls -l /home/ylk/test-dir-symlink*
lrwxrwxrwx 1 ylk ylk 24 Feb 19 21:15 /home/ylk/test-dir-symlink ->
/local/home/ylk/test-dir/
lrwxrwxrwx 1 ylk ylk 8 Feb 19 21:27 /home/ylk/test-dir-symlink2 ->
test-dir/

Without this patch, the following behavior is observed when using open_dir_nofollow:

test-dir-symlink/ -> error
test-dir-symlink -> error
test-dir-symlink2 -> error
test-dir-symlink2/ -> no error

[gitstashpop]

@sunfishcode hope to get some feedback here if this is worse pursuing from your point of view. If yes, I'll fix the failing CI tests

[sunfishcode]

Sorry for the delay here!

A symlink to an absolute path will always cause a failure with cap-std, because cap-std is defined to use RESOLVE_BENEATH semantics, rather than RESOLVE_IN_ROOT semantics.

O_NOFOLLOW is not the same as RESOLVE_NO_SYMLINKS. O_NOFOLLOW only applies to the last component, while RESOLVE_NO_SYMLINKS disables all symlink resolution. And, when a path ends with /, the / is considered the last component. Consequently, opening test-dir-symlink2 with O_NOFOLLOW follows the symlink and succeeds. This matches the behavior of non-cap-std APIs, where opening test-dir-symlink2/ with O_NOFOLLOW also succeeds.

[sunfishcode]

As explained in my previous comment, it appears cap-std is working as intended here. If I'm mistaken, please reopen or file a new issue!