GNU bug report logs - #29475
filesystem does not allow ln to create bad symbolic link

Previous Next

Full log

Message #17 received at 29475 <at> debbugs.gnu.org (full text, mbox):

From: bug-coreutils <at> trodman.com
To: 29475 <at> debbugs.gnu.org, bug-coreutils <at> gnu.org
Subject: Re: bug#29475: filesystem (apparently cagefs) does not allow ln to
 create bad symbolic link
Date: Thu, 30 Nov 2017 18:59:21 -0600

On Mon 11/27/17 18:41 -0800 Paul Eggert wrote:
> bug-coreutils <at> trodman.com 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.