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
Thanks,
Ken
