coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ln -s A B fails if symlink B exists and its value is too long


From: Bernhard Voelker
Subject: Re: ln -s A B fails if symlink B exists and its value is too long
Date: Fri, 17 Jan 2014 08:23:00 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

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?= <address@hidden>
> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]