bug#29475: filesystem (apparently cagefs) does not allow ln to create bad symbolic link

[bug-coreutils]

On Mon 11/27/17 18:41 -0800 Paul Eggert wrote:
> address@hidden wrote:
> > stat("badlink", 0x7ffc0eb805a0)         = -1 ENOENT (No such file or 
> > directory)
> > symlink("not-there", "badlink")         = -1 ENOENT (No such file or 
> > directory)
> 
> My guess is that you've removed the working directory somehow, or are on a 
> buggy 
> filesystem that thinks the working directory has been removed. I can 
> reproduce 
> the situation as follows on Ubuntu 16.04.3:
> 
> $ cd /tmp
> $ mkdir d
> $ cd d
> $ rmdir /tmp/d
> $ LC_ALL=C strace ln -s a b
> ...
> stat("b", 0x7fffe6df6140)               = -1 ENOENT (No such file or 
> directory)
> symlink("a", "b")                       = -1 ENOENT (No such file or 
> directory)
> ...
> 
> The only suggestion I have is "don't do that". If memory serves, POSIX 
> doesn't 
> specify the behavior in this case.

Thanks for all your help Paul.

I talked w/a level one help person. They said the host distro is Cloudlinux, 
and the
filesystem is cagefs. My quick web search results:

    https://docs.cloudlinux.com/index.html?cagefs.html

>From my trial and error, this file system does not let you create bad sym 
>links. I just have to work
around it; tar up dirs in two passes one for sym links only, then the reverse. 
When untarring,
do non sym links first.

--
Tom