Re: symbolic link curiousity in 3.6.0

Hi Bruno, On Mar 29 15:02, Bruno Haible via Cygwin wrote: > Corinna Vinschen wrote: > > > Regarding what acl_extended_file() does, there is the man page by > > > Andreas Grünbacher: > > > https://www.kernel.org/doc/man-pages/online/pages/man3/acl_extended_file.3.html > > > Gnulib is not the only u

Re: symbolic link curiousity in 3.6.0

On 2025-04-04 10:40, Pádraig Brady wrote: Is this patch is OK to be applied to gnulib, with the tweaks Corinna mentioned? Yes, I did that just now, and propagated it into coreutils. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documen

Re: symbolic link curiousity in 3.6.0

On 2025-03-30 05:50, Corinna Vinschen wrote: The definition of O_PATH requires an additional #include Thanks, I added that and installed the patch into Gnulib. However, assuming not only Cygwin is affected, shouldn't the patch rather use O_PATH if it's available, O_RDONLY if not? I h

Re: symbolic link curiousity in 3.6.0

On 29/03/2025 16:31, Paul Eggert wrote: On 3/29/25 04:30, Corinna Vinschen wrote: What it should do if only the POSIX.1e draft 17 functions are available is something along these lines: Yes, that sounds like a better approach. However, shouldn't it use O_PATH not O_RDONLY? We might lack read a

Re: symbolic link curiousity in 3.6.0

On Apr 1 15:32, Paul Eggert via Cygwin wrote: > > > traditionally (and I'm talking about 7th edition Unix) a single > > > output line of 'ls' corresponded to a state obtained atomically from the > > > file system. I realize we can't always do that nowadays but the further we > > > depart from it,

Re: symbolic link curiousity in 3.6.0

traditionally (and I'm talking about 7th edition Unix) a single output line of 'ls' corresponded to a state obtained atomically from the file system. I realize we can't always do that nowadays but the further we depart from it, the worse 'ls' users will be. The link dereferencing is a courtesy of

Re: symbolic link curiousity in 3.6.0

Greetings, Paul Eggert! > On 3/31/25 12:26, Corinna Vinschen wrote: >> ls(1) always potentially shows a past state anyway. > Sure, but traditionally (and I'm talking about 7th edition Unix) a single > output line of 'ls' corresponded to a state obtained atomically from the > file system. I realiz

Re: symbolic link curiousity in 3.6.0

On 3/31/25 12:26, Corinna Vinschen wrote: ls(1) always potentially shows a past state anyway. Sure, but traditionally (and I'm talking about 7th edition Unix) a single output line of 'ls' corresponded to a state obtained atomically from the file system. I realize we can't always do that nowad

Re: symbolic link curiousity in 3.6.0

On Mar 31 12:12, Paul Eggert via Cygwin wrote: > On 3/31/25 11:27, Pádraig Brady wrote: > > The file could be deleted at any time. > > We're just suppressing errors in the edge case it's deleted > > More generally, though, the file could be renamed and another put in its > place, which means that

Re: symbolic link curiousity in 3.6.0

On 3/31/25 11:27, Pádraig Brady wrote: The file could be deleted at any time. We're just suppressing errors in the edge case it's deleted More generally, though, the file could be renamed and another put in its place, which means that an attacker could cause 'ls' to generate a line that does

Re: symbolic link curiousity in 3.6.0

On 31/03/2025 17:32, Paul Eggert wrote: On 2025-03-30 07:26, Pádraig Brady wrote: On 30/03/2025 13:50, Corinna Vinschen wrote: In terms of coreutils, I think either ls(1) gobble_file() or file_has_aclinfo_cache() should still handle ENOENT from file_has_aclinfo() and not print any error message

Re: symbolic link curiousity in 3.6.0

On 2025-03-30 07:26, Pádraig Brady wrote: On 30/03/2025 13:50, Corinna Vinschen wrote: In terms of coreutils, I think either ls(1) gobble_file() or file_has_aclinfo_cache() should still handle ENOENT from file_has_aclinfo() and not print any error message.  After all, due to the preconditions fo

Re: symbolic link curiousity in 3.6.0

Hi Bruno, On Mar 29 15:02, Bruno Haible via Cygwin wrote: > Corinna Vinschen wrote: > > > Regarding what acl_extended_file() does, there is the man page by > > > Andreas Grünbacher: > > > https://www.kernel.org/doc/man-pages/online/pages/man3/acl_extended_file.3.html > > > Gnulib is not the only u

Re: symbolic link curiousity in 3.6.0

On 30/03/2025 13:50, Corinna Vinschen wrote: Hi Paul, thanks for the patch. On Mar 29 10:31, Paul Eggert via Cygwin wrote: On 3/29/25 04:30, Corinna Vinschen wrote: What it should do if only the POSIX.1e draft 17 functions are available is something along these lines: Yes, that sounds like

Re: symbolic link curiousity in 3.6.0

Hi Paul, thanks for the patch. On Mar 29 10:31, Paul Eggert via Cygwin wrote: > On 3/29/25 04:30, Corinna Vinschen wrote: > > What it should do if only the POSIX.1e draft 17 functions are available > > is something along these lines: > > Yes, that sounds like a better approach. However, shouldn'

Re: symbolic link curiousity in 3.6.0

On 2025-03-29 12:14, Brian Inglis via Cygwin wrote: On 2025-03-29 08:02, Bruno Haible via Cygwin wrote: Corinna Vinschen wrote: Regarding what acl_extended_file() does, there is the man page by Andreas Grünbacher: https://www.kernel.org/doc/man-pages/online/pages/man3/acl_extended_file.3.html G

Re: symbolic link curiousity in 3.6.0

On 2025-03-29 08:02, Bruno Haible via Cygwin wrote: Corinna Vinschen wrote: Regarding what acl_extended_file() does, there is the man page by Andreas Grünbacher: https://www.kernel.org/doc/man-pages/online/pages/man3/acl_extended_file.3.html Gnulib is not the only user of acl_extended_file(); th

Re: symbolic link curiousity in 3.6.0

On 3/29/25 04:30, Corinna Vinschen wrote: What it should do if only the POSIX.1e draft 17 functions are available is something along these lines: Yes, that sounds like a better approach. However, shouldn't it use O_PATH not O_RDONLY? We might lack read access. Does the attached Gnulib patch

Re: symbolic link curiousity in 3.6.0

Corinna Vinschen wrote: > > Regarding what acl_extended_file() does, there is the man page by > > Andreas Grünbacher: > > https://www.kernel.org/doc/man-pages/online/pages/man3/acl_extended_file.3.html > > Gnulib is not the only user of acl_extended_file(); therefore I would > > suggest that Cygwin

Re: symbolic link curiousity in 3.6.0

On Mar 29 13:12, Corinna Vinschen via Cygwin wrote: > On Mar 29 12:43, Bruno Haible via Cygwin wrote: > > OK, and what does this mean for the *files* created in such a directory? > > Just for clarity, permissions in Windows are *always* defined by an ACL. > There's no such thing as default POSIX p

Re: symbolic link curiousity in 3.6.0

On Mar 29 12:58, Bruno Haible via Cygwin wrote: > Corinna Vinschen wrote: > > Btw., while I was testing test-file-has-acl.sh, I found two more bugs, > > one in test-file-has-acl.sh, and one (a problem of account handling in > > Windows) in Cygwin's setfacl(1). Together with the above change to > >

Re: symbolic link curiousity in 3.6.0

On Mar 29 12:43, Bruno Haible via Cygwin wrote: > Hi Corinna, > > > c) The expectations of test-file-has-acl.sh are wrong. > > The Cygwin-specific part of that unit test has minimal expectations: > > # Set an ACL for a group. > if setfacl -m group:0:1 tmpfile0; then > >

Re: symbolic link curiousity in 3.6.0

Corinna Vinschen wrote: > Btw., while I was testing test-file-has-acl.sh, I found two more bugs, > one in test-file-has-acl.sh, and one (a problem of account handling in > Windows) in Cygwin's setfacl(1). Together with the above change to > acl_extended_file(), fixing the bug in setfacl(1) is suff

Re: symbolic link curiousity in 3.6.0

Hi Corinna, > c) The expectations of test-file-has-acl.sh are wrong. The Cygwin-specific part of that unit test has minimal expectations: # Set an ACL for a group. if setfacl -m group:0:1 tmpfile0; then func_test_has_acl tmpfile0 yes # Remove the ACL for t

Re: symbolic link curiousity in 3.6.0

Hi Pádraig, thanks for your reply! On Mar 28 20:30, Pádraig Brady via Cygwin wrote: > On 28/03/2025 14:30, Bruno Haible via Gnulib discussion list wrote: > > [CCing bug-gnulib] > > > > Corinna Vinschen wrote in > > : > > Responding

Re: symbolic link curiousity in 3.6.0

Hi Bruno, thanks for your quick reply! On Mar 28 15:30, Bruno Haible via Cygwin wrote: > [CCing bug-gnulib] > > Corinna Vinschen wrote in > : > > I found the problem, it's in a gnulib header. See below. > > ... > > Gnulib's acl-inte

Re: symbolic link curiousity in 3.6.0

On 28/03/2025 14:30, Bruno Haible via Gnulib discussion list wrote: [CCing bug-gnulib] Corinna Vinschen wrote in : Responding to previous messages in the above thread, I think the triggering commit in coreutils 9.6 was: https://gi

Re: symbolic link curiousity in 3.6.0

On 2025-03-28 08:30, Bruno Haible via Cygwin wrote: [CCing bug-gnulib] Corinna Vinschen wrote in : I found the problem, it's in a gnulib header. See below. ... Gnulib's acl-internal.h contains this: /* Linux-specific */ /* C

Re: symbolic link curiousity in 3.6.0

[CCing bug-gnulib] Corinna Vinschen wrote in : > I found the problem, it's in a gnulib header. See below. > ... > Gnulib's acl-internal.h contains this: > > /* Linux-specific */ > /* Cygwin >= 2.5 implements this function, but it

Re: symbolic link curiousity in 3.6.0

Hi Bruno, I found the problem, it's in a gnulib header. See below. On Mar 28 12:21, Corinna Vinschen via Cygwin wrote: > On Mar 28 10:59, Corinna Vinschen via Cygwin wrote: > > [Adding Bruno Haible] > > > > Hi Bruno, > > > > can you please take a look? To reiterate, with coreutils 9.6: > > >

Re: symbolic link curiousity in 3.6.0

On Mar 28 10:59, Corinna Vinschen via Cygwin wrote: > [Adding Bruno Haible] > > Hi Bruno, > > can you please take a look? To reiterate, with coreutils 9.6: > > $ ln -s foo bar > $ ls -l bar > ls: bar: Not supported > lrwxrwxrwx 1 corinna vinschen 3 Mar 27 10:20 bar -> foo > > The intro

Re: symbolic link curiousity in 3.6.0

[Adding Bruno Haible] Hi Bruno, can you please take a look? To reiterate, with coreutils 9.6: $ ln -s foo bar $ ls -l bar ls: bar: Not supported lrwxrwxrwx 1 corinna vinschen 3 Mar 27 10:20 bar -> foo The introducing commit in coreutils is apparently commit b58e321c8d5dd ("ls: suppress

Re: symbolic link curiousity in 3.6.0

On Mar 25 15:12, Mark Geisert via Cygwin wrote: > > > > Your ls output shows an at-sign after the name "bar". You're > > probably using an alias for ls including the -F option. Can you > > paste your alias here? > > alias ls='ls -AF --color -bv -T 0' > > The oddity occurs even if I use /bin/ls

Re: symbolic link curiousity in 3.6.0

Hi Corinna, On 3/25/2025 2:56 AM, Corinna Vinschen via Cygwin wrote: On Mar 25 02:25, Mark Geisert via Cygwin wrote: This occurs on the released 3.6.0 but not in 3.6.0 test build 327. /tmp ls foo bar ls: cannot access 'foo': No such file or directory ls: cannot access 'bar': No such file or di

Re: symbolic link curiousity in 3.6.0

On Mar 25 02:25, Mark Geisert via Cygwin wrote: > This occurs on the released 3.6.0 but not in 3.6.0 test build 327. > > /tmp ls foo bar > ls: cannot access 'foo': No such file or directory > ls: cannot access 'bar': No such file or directory > > /tmp ln -s foo bar > > /tmp ls foo bar > ls: cann