[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: a real fts.c bug + fix
From: |
Jim Meyering |
Subject: |
Re: a real fts.c bug + fix |
Date: |
Thu, 12 Jan 2006 19:10:45 +0100 |
Paul Eggert <address@hidden> wrote:
> Jim Meyering <address@hidden> writes:
>
>> If any of you know of a system with file name resolution code that
>> doesn't fail for a chain of 400 symlinks, or for which you get a
>> different diagnostic than `Too many levels of symbolic links' (ELOOP),
>> please provide details.
>
> On Solaris 8 through 10 (at least), perror says this for ELOOP:
>
> Number of symbolic links encountered during path name traversal exceeds
> MAXSYMLINKS
>
> which causes the coreutils tests to fail (at least, this was true as
> of about 24 hours ago, but I hadn't gotten around to looking into it
> yet). It could be a System V ism. glibc used to do the same thing,
> when it supported SunOS.
Thanks for checking that!
Here's an untested patch:
2006-01-12 Jim Meyering <address@hidden>
* tests/du/long-sloop: Adjust not to hard-code the expected
diagnostic corresponding to ELOOP. Solaris' diagnostic differs
from that of Linux/libc. Reported by Paul Eggert.
Index: long-sloop
===================================================================
RCS file: /fetish/cu/tests/du/long-sloop,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -p -u -r1.5 -r1.6
--- long-sloop 12 Jan 2006 14:45:15 -0000 1.5
+++ long-sloop 12 Jan 2006 18:08:18 -0000 1.6
@@ -42,8 +42,15 @@ fi
# If a system can handle this many symlinks in a file name,
# just skip this test.
+
+# The following also serves to record in `err' the string
+# corresponding to strerror (ELOOP). This is necessary because while
+# Linux/libc gives `Too many levels of symbolic links', Solaris
+# renders it as `Number of symbolic links encountered during path
+# name traversal exceeds MAXSYMLINKS'.
+
file=1`printf %${n}s ' '|sed 's, ,/s,g'`
-cat $file > /dev/null 2>&1 && \
+cat $file > /dev/null 2> err && \
{
cat <<EOF >&2
$0: Your systems appears to be able to handle more than $n symlinks
@@ -51,6 +58,7 @@ in file name resolution, so skipping thi
EOF
(exit 77); exit 77
}
+too_many=`sed 's/.*: //' err`
fail=0
@@ -58,10 +66,9 @@ fail=0
# With coreutils-5.94 we get a diagnostic like this:
# du: cannot access `1/s/s/s/.../s': Too many levels of symbolic links
du -L 1 > /dev/null 2> out1 && fail=1
-sed "s,1/s/s/s/[/s]*','," out1 > out || fail=1
-cat <<\EOF > exp || fail=1
-du: cannot access `': Too many levels of symbolic links
-EOF
+sed "s, .1/s/s/s/[/s]*',," out1 > out || fail=1
+
+echo "du: cannot access: $too_many" > exp || fail=1
cmp out exp || fail=1
test $fail = 1 && diff out exp 2> /dev/null