#2130 Issue closed: 985_fix_broken_links.sh reports "Failed to copy symlink target" for directories

Labels: enhancement, cleanup, fixed / solved / done

OliverO2 opened issue at 2019-04-29 17:08:

  • ReaR version ("/usr/sbin/rear -V"): 2.4 / Git (f3157906)

  • OS version ("cat /etc/rear/os.conf" or "lsb_release -a" or "cat /etc/os-release"): Ubuntu 18.04.2 LTS

  • System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device): x86 compatible

  • Description of the issue (ideally so that others can reproduce it):

    Log file entry:

    cp: -r not specified; omitting directory '/usr/src/linux-headers-4.18.0-18-generic'
[...] Failed to copy symlink target '/usr/src/linux-headers-4.18.0-18-generic'

    Original system:

    # find / -mount -lname /usr/src/linux-headers-4.18.0-18-generic
/lib/modules/4.18.0-18-generic/build

In this case it makes sense not to copy the directory. If directories, which are symbolic link targets, should never be copied by default, the log message could state that. In any case, it would be helpful to include the symbolic link source in the message.

jsmeix commented at 2019-04-30 07:58:

I don't know if directories, which are symbolic link targets, should not be copied.
I think directories, which are symbolic link targets, must never be copied recursively.
But I wonder if a plain empty directory should be recreated in the recovery system.
Could an empty directory, which was a symbolic link target, be useful in the
recovery system?
I mean:
I already create the parent directories of a symbolic link target file.
Why not also create plain empty symbolic link target directories?
Empty directories cost basically nothing in the recovery system
and in some special cases they might be even needed?

jsmeix commented at 2019-05-03 12:15:

With https://github.com/rear/rear/pull/2131 merged this issue is fixed.

[Export of Github issue for rear/rear.]