GNU bug report logs - #9634
Coreutils 8.13 - Orphaned symlinks start with 'argetm' when using dircolors

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 9634 in the body.
You can then email your comments to 9634 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jason Glassey <replica9000 <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: Coreutils 8.13 - Orphaned symlinks start with 'argetm' when using
	dircolors
Date: Thu, 29 Sep 2011 16:48:17 -0400

I had seen this was a bug supposed to be fixed in Coreutils 8.3, but I
can still replicate this bug in
Coreutils 8.13

In my .bashrc file, I have this alias:

alias ls='ls -Lp --color=auto --group-directories-first'

Symlinks appear fine when the target exist, but when the symlink
becomes orphaned (such as a
symlink to a removable drive), the symlink starts with 'argetm'

I only get this problem when I use the '--dereference' option, and
when the target does not exist
when using dircolors.

Message #8 received at 9634 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Jason Glassey <replica9000 <at> gmail.com>
Cc: 9634 <at> debbugs.gnu.org
Subject: Re: bug#9634: Coreutils 8.13 - Orphaned symlinks start with 'argetm'
	when using dircolors
Date: Fri, 30 Sep 2011 21:38:49 +0100

On 09/29/2011 09:48 PM, Jason Glassey wrote:
> I had seen this was a bug supposed to be fixed in Coreutils 8.3, but I
> can still replicate this bug in
> Coreutils 8.13
> 
> In my .bashrc file, I have this alias:
> 
> alias ls='ls -Lp --color=auto --group-directories-first'
> 
> Symlinks appear fine when the target exist, but when the symlink
> becomes orphaned (such as a
> symlink to a removable drive), the symlink starts with 'argetm'
> 
> I only get this problem when I use the '--dereference' option, and
> when the target does not exist
> when using dircolors.

Confirmed. I'll fix it with something like the following,
and I'll add a test too.

cheers,
Pádraig.

diff --git a/src/ls.c b/src/ls.c
index 680a7c3..e7d0a5c 100644
--- a/src/ls.c
+++ b/src/ls.c
@@ -4203,10 +4203,7 @@ print_color_indicator (const struct fileinfo *f, bool symlink_target)
             type = C_STICKY;
         }
       else if (S_ISLNK (mode))
-        type = ((!linkok
-                 && (!STRNCMP_LIT (color_indicator[C_LINK].string, "target")
-                     || color_indicator[C_ORPHAN].string))
-                ? C_ORPHAN : C_LINK);
+        type = C_LINK;
       else if (S_ISFIFO (mode))
         type = C_FIFO;
       else if (S_ISSOCK (mode))
@@ -4241,6 +4238,14 @@ print_color_indicator (const struct fileinfo *f, bool symlink_target)
         }
     }

+  /* Adjust the color for orphaned symlinks.  */
+  if (type == C_LINK && !linkok)
+    {
+      if (!STRNCMP_LIT (color_indicator[C_LINK].string, "target")
+          || color_indicator[C_ORPHAN].string)
+        type = C_ORPHAN;
+    }
+
   {
     const struct bin_str *const s
       = ext ? &(ext->seq) : &color_indicator[type];

Message #11 received at 9634 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Jason Glassey <replica9000 <at> gmail.com>
Cc: 9634 <at> debbugs.gnu.org
Subject: Re: bug#9634: Coreutils 8.13 - Orphaned symlinks start with 'argetm'
	when using dircolors
Date: Fri, 30 Sep 2011 22:49:20 +0200

Jason Glassey wrote:
> I had seen this was a bug supposed to be fixed in Coreutils 8.3, but I
> can still replicate this bug in
> Coreutils 8.13
>
> In my .bashrc file, I have this alias:
>
> alias ls='ls -Lp --color=auto --group-directories-first'
>
> Symlinks appear fine when the target exist, but when the symlink
> becomes orphaned (such as a
> symlink to a removable drive), the symlink starts with 'argetm'
>
> I only get this problem when I use the '--dereference' option, and
> when the target does not exist
> when using dircolors.

Thanks for the report.
Between yours and the one in http://bugs.debian.org/586765,
I was able to create a stand-alone reproducer.
The trick was to realize that you have customized your
LS_COLORS envvar to include ln=target.
Do this in an empty directory:

    $ ln -s /no-such dangle
    $ env LS_COLORS=ln=target ls --dereference --color
    ls: cannot access dangle: No such file or directory
    argetmdangle

While looking at that, I noticed two minor problems, fixed by this.
Pádraig, I expect to push this before your fix.  It looks like it
will be easy for you to adjust your patch accordingly.

From 4f38e9f24971762540da9d5457dfa9e5e03d53ee Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering <at> redhat.com>
Date: Fri, 30 Sep 2011 20:13:01 +0200
Subject: [PATCH] ls: avoid reading beyond end of color indicator

At first this looked like a buffer overrun, since there was no test
to ensure that the buffer length was 6.  However, since the LS_COLORS
string is NUL-terminated and since settings within it are separated by
":" there was neither the risk of reading beyond end of buffer nor risk
of a false-positive match.
* src/ls.c (print_color_indicator): Use color_symlink_as_referent
rather than manually comparing against "target" again.
* src/system.h (STRNCMP_LIT): Correct description in comment.
---
 src/ls.c     |    2 +-
 src/system.h |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/ls.c b/src/ls.c
index 680a7c3..c1b1918 100644
--- a/src/ls.c
+++ b/src/ls.c
@@ -4204,7 +4204,7 @@ print_color_indicator (const struct fileinfo *f, bool symlink_target)
         }
       else if (S_ISLNK (mode))
         type = ((!linkok
-                 && (!STRNCMP_LIT (color_indicator[C_LINK].string, "target")
+                 && (color_symlink_as_referent
                      || color_indicator[C_ORPHAN].string))
                 ? C_ORPHAN : C_LINK);
       else if (S_ISFIFO (mode))
diff --git a/src/system.h b/src/system.h
index 107dbd5..ec64cd0 100644
--- a/src/system.h
+++ b/src/system.h
@@ -188,7 +188,7 @@ select_plural (uintmax_t n)
 #define STREQ_LEN(a, b, n) (strncmp (a, b, n) == 0)
 #define STRPREFIX(a, b) (strncmp(a, b, strlen (b)) == 0)

-/* Just like strncmp, but the first argument must be a literal string
+/* Just like strncmp, but the second argument must be a literal string
    and you don't specify the length.  */
 #define STRNCMP_LIT(s, literal) \
   strncmp (s, "" literal "", sizeof (literal) - 1)
--
1.7.7.rc0.362.g5a14

Message #14 received at 9634 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Jim Meyering <jim <at> meyering.net>
Cc: Jason Glassey <replica9000 <at> gmail.com>, 9634 <at> debbugs.gnu.org
Subject: Re: bug#9634: Coreutils 8.13 - Orphaned symlinks start with 'argetm'
	when using dircolors
Date: Fri, 30 Sep 2011 22:49:09 +0100

On 09/30/2011 09:49 PM, Jim Meyering wrote:
> Jason Glassey wrote:
>> I had seen this was a bug supposed to be fixed in Coreutils 8.3, but I
>> can still replicate this bug in
>> Coreutils 8.13
>>
>> In my .bashrc file, I have this alias:
>>
>> alias ls='ls -Lp --color=auto --group-directories-first'
>>
>> Symlinks appear fine when the target exist, but when the symlink
>> becomes orphaned (such as a
>> symlink to a removable drive), the symlink starts with 'argetm'
>>
>> I only get this problem when I use the '--dereference' option, and
>> when the target does not exist
>> when using dircolors.
> 
> Thanks for the report.
> Between yours and the one in http://bugs.debian.org/586765,
> I was able to create a stand-alone reproducer.
> The trick was to realize that you have customized your
> LS_COLORS envvar to include ln=target.
> Do this in an empty directory:
> 
>     $ ln -s /no-such dangle
>     $ env LS_COLORS=ln=target ls --dereference --color
>     ls: cannot access dangle: No such file or directory
>     argetmdangle
> 
> While looking at that, I noticed two minor problems, fixed by this.
> Pádraig, I expect to push this before your fix.  It looks like it
> will be easy for you to adjust your patch accordingly.

Heh, of course we picked the same time to handle this :)
Your fixes look good, and I'll adjust mine mentioning
the debian bug too.

thanks,
Pádraig.

Message #17 received at 9634 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: Jason Glassey <replica9000 <at> gmail.com>, 9634 <at> debbugs.gnu.org
Subject: Re: bug#9634: Coreutils 8.13 - Orphaned symlinks start with 'argetm'
	when using dircolors
Date: Fri, 30 Sep 2011 23:51:29 +0200

Pádraig Brady wrote:

> On 09/30/2011 09:49 PM, Jim Meyering wrote:
>> Jason Glassey wrote:
>>> I had seen this was a bug supposed to be fixed in Coreutils 8.3, but I
>>> can still replicate this bug in
>>> Coreutils 8.13
>>>
>>> In my .bashrc file, I have this alias:
>>>
>>> alias ls='ls -Lp --color=auto --group-directories-first'
>>>
>>> Symlinks appear fine when the target exist, but when the symlink
>>> becomes orphaned (such as a
>>> symlink to a removable drive), the symlink starts with 'argetm'
>>>
>>> I only get this problem when I use the '--dereference' option, and
>>> when the target does not exist
>>> when using dircolors.
>>
>> Thanks for the report.
>> Between yours and the one in http://bugs.debian.org/586765,
>> I was able to create a stand-alone reproducer.
>> The trick was to realize that you have customized your
>> LS_COLORS envvar to include ln=target.
>> Do this in an empty directory:
>>
>>     $ ln -s /no-such dangle
>>     $ env LS_COLORS=ln=target ls --dereference --color
>>     ls: cannot access dangle: No such file or directory
>>     argetmdangle
>>
>> While looking at that, I noticed two minor problems, fixed by this.
>> Pádraig, I expect to push this before your fix.  It looks like it
>> will be easy for you to adjust your patch accordingly.
>
> Heh, of course we picked the same time to handle this :)
> Your fixes look good, and I'll adjust mine mentioning
> the debian bug too.

Thanks for the review.  Pushed.

Message #22 received at 9634-done <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Jim Meyering <jim <at> meyering.net>
Cc: 9634-done <at> debbugs.gnu.org, Jason Glassey <replica9000 <at> gmail.com>
Subject: Re: bug#9634: Coreutils 8.13 - Orphaned symlinks start with 'argetm'
	when using dircolors
Date: Sat, 01 Oct 2011 02:18:29 +0100

[Message part 1 (text/plain, inline)]

On 09/30/2011 10:51 PM, Jim Meyering wrote:
> Pádraig Brady wrote:
>>
>> Your fixes look good, and I'll adjust mine mentioning
>> the debian bug too.
> 
> Thanks for the review.  Pushed.
> 

And I applied the attached.

cheers,
Pádraig.

[ls-L-argetm.diff (text/plain, attachment)]

Message #25 received at 9634 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: 9634 <at> debbugs.gnu.org
Subject: Re: bug#9634: Coreutils 8.13 - Orphaned symlinks start with 'argetm'
	when using dircolors
Date: Sat, 01 Oct 2011 02:38:04 +0100

On 10/01/2011 02:18 AM, Pádraig Brady wrote:
> On 09/30/2011 10:51 PM, Jim Meyering wrote:
>> Pádraig Brady wrote:
>>>
>>> Your fixes look good, and I'll adjust mine mentioning
>>> the debian bug too.
>>
>> Thanks for the review.  Pushed.
>>
> 
> And I applied the attached.

Actually that deserves a NEWS entry,
which I've just applied.

cheers,
Pádraig.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.