On 01/17/2014 05:03 AM, Pádraig Brady wrote: > I'll push the attached soon to fix this.
Thanks. > From 672b0b5f1023f7f433973edec7376fce330cb2a2 Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?P=C3=A1draig=20Brady?= <[email protected]> > Date: Fri, 17 Jan 2014 03:54:29 +0000 > Subject: [PATCH] ln: fix replacing symbolic links whose targets can't exist > diff --git a/tests/ln/sf-1.sh b/tests/ln/sf-1.sh > index 3f4f8f1..ecf3aae 100755 > --- a/tests/ln/sf-1.sh > +++ b/tests/ln/sf-1.sh > +# Ensure we replace symlinks that don't or can't link to an existing target. > +# coreutils-8.22 would fail to replace {ENOTDIR,ELOOP,ENAMETOOLONG}_link > below. > +name_max_plus1=$(expr $(stat -f -c %l .) + 1) > +long_name=$(printf '%0*d' $name_max_plus1 0) Is there a chance that the above stat might fail? In such a case, long_name would just be '0'. Maybe adding this would do: test $name_max_plus1 -gt 1 || framework_failure_ or even directly verifying ENAMETOOLONG afterward: stat --dereference ENAMETOOLONG_link 2> err && framework_failure_ grep 'too long' err || framework_failure_ +1 otherwise. Thanks & have a nice day, Berny
