#2133 Issue closed: 100_copy_as_is.sh can get in conflict with what 010_merge_skeletons.sh did before¶

Labels: enhancement, cleanup, no-issue-activity

jsmeix opened issue at 2019-05-02 10:23:¶

See
https://github.com/rear/rear/pull/2132#issuecomment-487960213
for the original issue.

With current ReaR github master code
build/GNU/Linux/100_copy_as_is.sh can get in conflict
with what rescue/default/010_merge_skeletons.sh did before
when the COPY_AS_IS array contains a symlink to a directory
that was already created in ROOTFS_DIR by 010_merge_skeletons.sh

Example:

# mkdir /etc/myscripts

# echo myscript >/etc/myscripts/myscript

# ln -s /etc/myscripts /etc/scripts

# find /etc -ls | grep myscripts
... drwxr-xr-x ... /etc/myscripts
... -rw-r--r-- ... /etc/myscripts/myscript
... lrwxrwxrwx ... /etc/scripts -> /etc/myscripts

and in etc/rear/local.conf

COPY_AS_IS+=( /etc/scripts )

results

# usr/sbin/rear -D mkrescue
...
Copying files and directories
ERROR: Failed to copy files and directories in COPY_AS_IS minus COPY_AS_IS_EXCLUDE
Some latest log messages since the last called script 100_copy_as_is.sh:
  2019-05-02 11:55:13.392080693 Entering debugscripts mode via 'set -x'.
  2019-05-02 11:55:13.396251035 Copying files and directories
  2019-05-02 11:55:13.400265205 Files being copied: /root/rear.github.master/usr/share/rear /root/rear.github.master/var/lib/rear /dev /etc/inputrc /etc/protocols /etc/services /etc/rpc /etc/termcap /
  2019-05-02 11:55:13.402776151 Files being excluded: dev/shm dev/oracleasm dev/mapper dev/.udev /root/rear.github.master/var/lib/rear/output/rear-g243.iso dev/shm/* /etc/pki/tls/private /etc/pki/CA/p
  tar: Removing leading `/' from member names
  tar: etc/scripts: Cannot open: File exists
  tar: Removing leading `/' from hard link targets
  tar: Exiting with failure status due to previous errors
Aborting due to an error, check /root/rear.github.master/var/log/rear/rear-g243.log for details

I think as the current code is it is even good that it fails
in this particular case.

This particular case is only the tip of an iceberg:

In other cases it just blindly proceeds and COPY_AS_IS array elemets
can just overwrite anything that was already created in ROOTFS_DIR
by 010_merge_skeletons.sh - i.e. COPY_AS_IS can destroy needed
recovery system content.

Example:

# mkdir /etc/scripts

# echo my-system-setup >/etc/scripts/system-setup

# find /etc/scripts -ls
... drwxr-xr-x ... /etc/scripts

... -rw-r--r-- ... /etc/scripts/system-setup

and in etc/rear/local.conf

COPY_AS_IS+=( /etc/scripts )

results

# usr/sbin/rear -D mkrescue
...
Copying files and directories
Copying binaries and libraries
...
Running exit tasks
You should also rm -Rf /tmp/rear.CdodUBnLMNMmf3m

but now etc/scripts/system-setup in the recovery system
is overwritten by the content from /etc/scripts/system-setup
on the original system

# cat /tmp/rear.CdodUBnLMNMmf3m/rootfs/etc/scripts/system-setup
my-system-setup

I think we should test in build/GNU/Linux/100_copy_as_is.sh
if directories are already there and when files that are already there
would be overwrtitten.

github-actions commented at 2020-06-29 01:37:¶

Stale issue message

---

[Export of Github issue for rear/rear.]