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

[Pádraig Brady]

On 12/27/2013 03:47 AM, Ken Irving wrote:
> I happened to run into a case were ln -s exited with a confusing message,
> and reduced it to the following:
> 
>     ln -s $(printf '%0.sx' {1..256}) len256
>     ln -s x len256
> 
> (where the printf is there just to create a value 256 bytes long).
> The second command exits with value 1 and emits this message:
> 
>     ln: accessing `len256': File name too long
> 
> The 'File name' here is the existing symlink's value, normally the target
> file but in this case just a non-resolving string.  The issue does not
> occur if that value is less than 256 bytes.
> 
> The ln -f option would be required to actually force a symlink to be
> redefined, but is not needed for the message to be emitted.
> 
> I don't know if this is a bug, and don't know where it's happening,
> but just thought I should post a note about the condition as observed.
> Symlink values are otherwise quite unconstrained, do not need to resolve
> to a file, and can be longer than 256 bytes. ... up to 4095 on my system.
> 
>     $ uname -a; dpkg -S $(which ln); dpkg -l | grep coreutils
>     Linux shand 3.2.0-4-686-pae #1 SMP Debian 3.2.46-1+deb7u1 i686 GNU/Linux
>     coreutils: /bin/ln
>     ii  coreutils      8.13-3.5     i386         GNU core utilities

This is a bug and happens when ln tries to determine of the last arg is a 
directory.
It does a stat(2) which gives this error. ENOENT is specifically ignored, but it
seems like others should be too. You can see the source of the error with:

$ stat -L len256
stat: cannot stat `len256': File name too long

When resetting symlinks to point to somewhere else I always use -nsf
and that does avoid the issue here too.

thanks,
Pádraig.