bug#63245: Potential regression: cp --preserve=mode or --preserve=all fails to copy files from subdirectory
Pádraig Brady writes: > On 05/05/2023 02:39, Sam James wrote: >> Pádraig Brady writes: >> >>> On 04/05/2023 12:27, Pádraig Brady wrote: On 04/05/2023 07:27, Schlomo Schapiro wrote: > Hi Pádraig, > > thank you, that will not yet fix the problem in the older distros? What > about the RPM world with Fedora/RHEL and Archlinux? As far as I can tell > all cp version 9.x are affected by this. I'll handle the Fedora 37/38 fixes. RHEL/Centos and current Archlinux are not affected AFAICS. >>> >>> Fedora 37 and 38 updates are now pending (cc Kamil): >>> https://bodhi.fedoraproject.org/updates/FEDORA-2023-65365355b3 >>> https://bodhi.fedoraproject.org/updates/FEDORA-2023-4beb422aac >>> >>> The Fedora patches should also apply to the debian bookworm package, >>> so I've opened bugs accordingly at: >>> >>> https://bugs.debian.org/1035530 >>> https://bugs.debian.org/1035531 >>> >>> Schlomo, the second one is the one you're particularly interested in. >> This is relevant to coreutils-9.3, right? > > Right. Specifically only this bug applies to 9.3. I.e.: > https://github.com/coreutils/coreutils/commit/c6b1fe434 > >> In that case, the only way >> I found out Gentoo was affected was by reading bug-coreutils by chance. >> It's not feasible for all package maintainers to read all bug >> trackers >> regularly for all software in their distributions. >> If it's worth filing bug reports in each distro for, it's either >> worth >> a new release > Right. I didn't inform distros that generally go with the latest coreutils > (including Fedora rawhide), as I was planning to do a 9.4 release soonish > to address this (and other bugs), and so it would get picked up automatically. > That works too, thank you very much! :) >> or at least an email to the distributi...@lists.linux.dev mailing list. > > TIL > best, sam signature.asc Description: PGP signature
bug#63245: Potential regression: cp --preserve=mode or --preserve=all fails to copy files from subdirectory
On 2023-05-03 09:39, Pádraig Brady wrote:
The attached patch should address this in coreutils.
Thanks for fixing that. This area of the code is confusing, and I
attempted to simplify/clarify slightly by installing the attached
cleanup patch. This shouldn't affect behavior.From 300af7869161a3618e28cbae3daefc25c8267efe Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Fri, 5 May 2023 11:03:25 -0700
Subject: [PATCH] cp: -p --parents: minor cleanup of previous patch
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
This doesn’t change behavior; it just clarifies the code a bit.
* src/cp.c (re_protect): New arg DST_SRC_NAME, for clarity, and so
that we need to skip '/'s only once. Caller changed.
Rename a couple of local variables to try to make things clearer.
---
src/cp.c | 55 ++-
1 file changed, 30 insertions(+), 25 deletions(-)
diff --git a/src/cp.c b/src/cp.c
index 00a5cb813..619eb8260 100644
--- a/src/cp.c
+++ b/src/cp.c
@@ -278,10 +278,13 @@ regular file.\n\
exit (status);
}
-/* Ensure that parents of CONST_DST_NAME aka DST_DIRFD+DST_RELNAME have the
- correct protections, for the --parents option. This is done
- after all copying has been completed, to allow permissions
- that don't include user write/execute.
+/* Ensure that parents of CONST_DST_NAME have correct protections, for
+ the --parents option. This is done after all copying has been
+ completed, to allow permissions that don't include user write/execute.
+
+ DST_SRC_NAME is the suffix of CONST_DST_NAME that is the source file name,
+ DST_DIRFD+DST_RELNAME is equivalent to CONST_DST_NAME, and
+ DST_RELNAME equals DST_SRC_NAME after skipping any leading '/'s.
ATTR_LIST is a null-terminated linked list of structures that
indicates the end of the filename of each intermediate directory
@@ -296,19 +299,21 @@ regular file.\n\
when done. */
static bool
-re_protect (char const *const_dst_name, int dst_dirfd, char const *dst_fullname,
+re_protect (char const *const_dst_name, char const *dst_src_name,
+int dst_dirfd, char const *dst_relname,
struct dir_attr *attr_list, const struct cp_options *x)
{
struct dir_attr *p;
char *dst_name; /* A copy of CONST_DST_NAME we can change. */
- char *src_name; /* The relative source name in 'dst_name'. */
- char *full_src_name; /* The full source name in 'dst_name'. */
ASSIGN_STRDUPA (dst_name, const_dst_name);
- full_src_name = dst_name + (dst_fullname - const_dst_name);
- src_name = full_src_name;
- while (*src_name == '/')
-src_name++;
+
+ /* The suffix of DST_NAME that is a copy of the source file name,
+ possibly truncated to name a parent directory. */
+ char const *src_name = dst_name + (dst_src_name - const_dst_name);
+
+ /* Likewise, but with any leading '/'s skipped. */
+ char const *relname = dst_name + (dst_relname - const_dst_name);
for (p = attr_list; p; p = p->next)
{
@@ -325,7 +330,7 @@ re_protect (char const *const_dst_name, int dst_dirfd, char const *dst_fullname,
timespec[0] = get_stat_atime (>st);
timespec[1] = get_stat_mtime (>st);
- if (utimensat (dst_dirfd, src_name, timespec, 0))
+ if (utimensat (dst_dirfd, relname, timespec, 0))
{
error (0, errno, _("failed to preserve times for %s"),
quoteaf (dst_name));
@@ -335,7 +340,8 @@ re_protect (char const *const_dst_name, int dst_dirfd, char const *dst_fullname,
if (x->preserve_ownership)
{
- if (lchownat (dst_dirfd, src_name, p->st.st_uid, p->st.st_gid) != 0)
+ if (lchownat (dst_dirfd, relname, p->st.st_uid, p->st.st_gid)
+ != 0)
{
if (! chown_failure_ok (x))
{
@@ -345,18 +351,18 @@ re_protect (char const *const_dst_name, int dst_dirfd, char const *dst_fullname,
}
/* Failing to preserve ownership is OK. Still, try to preserve
the group, but ignore the possible error. */
- ignore_value (lchownat (dst_dirfd, src_name, -1, p->st.st_gid));
+ ignore_value (lchownat (dst_dirfd, relname, -1, p->st.st_gid));
}
}
if (x->preserve_mode)
{
- if (copy_acl (full_src_name, -1, dst_name, -1, p->st.st_mode) != 0)
+ if (copy_acl (src_name, -1, dst_name, -1, p->st.st_mode) != 0)
return false;
}
else if (p->restore_mode)
{
- if (lchmodat (dst_dirfd, src_name, p->st.st_mode) != 0)
+ if (lchmodat (dst_dirfd, relname, p->st.st_mode) != 0)
{
error (0, errno, _("failed to preserve permissions for %s"),
quoteaf (dst_name));
@@ -690,8 +696,7 @@ do_copy (int n_files, char **file, char const *target_directory,
char *dst_name;
bug#63245: Potential regression: cp --preserve=mode or --preserve=all fails to copy files from subdirectory
On 05/05/2023 02:39, Sam James wrote: Pádraig Brady writes: On 04/05/2023 12:27, Pádraig Brady wrote: On 04/05/2023 07:27, Schlomo Schapiro wrote: Hi Pádraig, thank you, that will not yet fix the problem in the older distros? What about the RPM world with Fedora/RHEL and Archlinux? As far as I can tell all cp version 9.x are affected by this. I'll handle the Fedora 37/38 fixes. RHEL/Centos and current Archlinux are not affected AFAICS. Fedora 37 and 38 updates are now pending (cc Kamil): https://bodhi.fedoraproject.org/updates/FEDORA-2023-65365355b3 https://bodhi.fedoraproject.org/updates/FEDORA-2023-4beb422aac The Fedora patches should also apply to the debian bookworm package, so I've opened bugs accordingly at: https://bugs.debian.org/1035530 https://bugs.debian.org/1035531 Schlomo, the second one is the one you're particularly interested in. This is relevant to coreutils-9.3, right? Right. Specifically only this bug applies to 9.3. I.e.: https://github.com/coreutils/coreutils/commit/c6b1fe434 In that case, the only way I found out Gentoo was affected was by reading bug-coreutils by chance. It's not feasible for all package maintainers to read all bug trackers regularly for all software in their distributions. If it's worth filing bug reports in each distro for, it's either worth a new release Right. I didn't inform distros that generally go with the latest coreutils (including Fedora rawhide), as I was planning to do a 9.4 release soonish to address this (and other bugs), and so it would get picked up automatically. > or at least an email to the distributi...@lists.linux.dev mailing list. TIL thanks! Pádraig
bug#63245: Potential regression: cp --preserve=mode or --preserve=all fails to copy files from subdirectory
On Friday, May 5, 2023 12:29:16 AM CEST Pádraig Brady wrote: > On 04/05/2023 12:27, Pádraig Brady wrote: > > On 04/05/2023 07:27, Schlomo Schapiro wrote: > >> Hi Pádraig, > >> > >> thank you, that will not yet fix the problem in the older distros? What > >> about the RPM world with Fedora/RHEL and Archlinux? As far as I can tell > >> all cp version 9.x are affected by this. > > > > I'll handle the Fedora 37/38 fixes. > > RHEL/Centos and current Archlinux are not affected AFAICS. > > Fedora 37 and 38 updates are now pending (cc Kamil): > https://bodhi.fedoraproject.org/updates/FEDORA-2023-65365355b3 > https://bodhi.fedoraproject.org/updates/FEDORA-2023-4beb422aac Thank you for taking care of it, Pádraig! Kamil > The Fedora patches should also apply to the debian bookworm package, > so I've opened bugs accordingly at: > > https://bugs.debian.org/1035530 > https://bugs.debian.org/1035531 > > Schlomo, the second one is the one you're particularly interested in. > > Marking this bug as completed upstream. > > cheers, > Pádraig
bug#63245: Potential regression: cp --preserve=mode or --preserve=all fails to copy files from subdirectory
Pádraig Brady writes: > On 04/05/2023 12:27, Pádraig Brady wrote: >> On 04/05/2023 07:27, Schlomo Schapiro wrote: >>> Hi Pádraig, >>> >>> thank you, that will not yet fix the problem in the older distros? What >>> about the RPM world with Fedora/RHEL and Archlinux? As far as I can tell >>> all cp version 9.x are affected by this. >> I'll handle the Fedora 37/38 fixes. >> RHEL/Centos and current Archlinux are not affected AFAICS. > > Fedora 37 and 38 updates are now pending (cc Kamil): > https://bodhi.fedoraproject.org/updates/FEDORA-2023-65365355b3 > https://bodhi.fedoraproject.org/updates/FEDORA-2023-4beb422aac > > The Fedora patches should also apply to the debian bookworm package, > so I've opened bugs accordingly at: > > https://bugs.debian.org/1035530 > https://bugs.debian.org/1035531 > > Schlomo, the second one is the one you're particularly interested in. This is relevant to coreutils-9.3, right? In that case, the only way I found out Gentoo was affected was by reading bug-coreutils by chance. It's not feasible for all package maintainers to read all bug trackers regularly for all software in their distributions. If it's worth filing bug reports in each distro for, it's either worth a new release, or at least an email to the distributi...@lists.linux.dev mailing list. signature.asc Description: PGP signature
bug#63245: Potential regression: cp --preserve=mode or --preserve=all fails to copy files from subdirectory
On 04/05/2023 12:27, Pádraig Brady wrote: On 04/05/2023 07:27, Schlomo Schapiro wrote: Hi Pádraig, thank you, that will not yet fix the problem in the older distros? What about the RPM world with Fedora/RHEL and Archlinux? As far as I can tell all cp version 9.x are affected by this. I'll handle the Fedora 37/38 fixes. RHEL/Centos and current Archlinux are not affected AFAICS. Fedora 37 and 38 updates are now pending (cc Kamil): https://bodhi.fedoraproject.org/updates/FEDORA-2023-65365355b3 https://bodhi.fedoraproject.org/updates/FEDORA-2023-4beb422aac The Fedora patches should also apply to the debian bookworm package, so I've opened bugs accordingly at: https://bugs.debian.org/1035530 https://bugs.debian.org/1035531 Schlomo, the second one is the one you're particularly interested in. Marking this bug as completed upstream. cheers, Pádraig
bug#63245: Potential regression: cp --preserve=mode or --preserve=all fails to copy files from subdirectory
On 04/05/2023 07:27, Schlomo Schapiro wrote: Hi Pádraig, thank you, that will not yet fix the problem in the older distros? What about the RPM world with Fedora/RHEL and Archlinux? As far as I can tell all cp version 9.x are affected by this. I'll handle the Fedora 37/38 fixes. RHEL/Centos and current Archlinux are not affected AFAICS. cheers, Pádraig
bug#63245: Potential regression: cp --preserve=mode or --preserve=all fails to copy files from subdirectory
Hi Pádraig, thank you, that will not yet fix the problem in the older distros? What about the RPM world with Fedora/RHEL and Archlinux? As far as I can tell all cp version 9.x are affected by this. Kind regards, Schlomo On Wed, 3 May 2023 at 22:05, Pádraig Brady wrote: > On 03/05/2023 18:45, Schlomo Schapiro wrote: > > Hi Pádraig, > > > > Wow, nice! That was really quick! > > > > how would this patch get into the affected distros as a bugfix? Then it > would actually help me as I can't ship a patched coreutils with ReaR. > > I expect the process would be something like: > > 1. merge this change to upstream coreutils (probably tomorrow). > 2. apply this change to debian bookworm > I'd also apply this related patch to bookworm: > https://github.com/coreutils/coreutils/commit/b54da709a.patch > 3. propagate those changes to ubuntu lunar > > cheers, > Pádraig >
bug#63245: Potential regression: cp --preserve=mode or --preserve=all fails to copy files from subdirectory
On 03/05/2023 18:45, Schlomo Schapiro wrote: Hi Pádraig, Wow, nice! That was really quick! how would this patch get into the affected distros as a bugfix? Then it would actually help me as I can't ship a patched coreutils with ReaR. I expect the process would be something like: 1. merge this change to upstream coreutils (probably tomorrow). 2. apply this change to debian bookworm I'd also apply this related patch to bookworm: https://github.com/coreutils/coreutils/commit/b54da709a.patch 3. propagate those changes to ubuntu lunar cheers, Pádraig
bug#63245: Potential regression: cp --preserve=mode or --preserve=all fails to copy files from subdirectory
Hi Pádraig, Wow, nice! That was really quick! how would this patch get into the affected distros as a bugfix? Then it would actually help me as I can't ship a patched coreutils with ReaR. Kind regards, Schlomo On Wed, 3 May 2023 at 18:40, Pádraig Brady wrote: > On 03/05/2023 10:27, Schlomo Schapiro wrote: > > Hello, > > > > I'm a maintainer of the Relax-and-Recover ( > https://relax-and-recover.org/) > > Open Source project and think that I might have found a major regression > in > > cp, starting somewhere with version 9. > > > > Please see > https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/2017414 > > and https://github.com/rear/rear/issues/2972 for how I found out about > this. > > > > Problem: > > > > We use a cp call like the following to copy various files and directory > > into a destination path with preserving the structure: > > > > cp --verbose -t DESTINATION -L --preserve=all --parents SOURCE... > > > > Over the last 10+ years that worked well on all Linux distros (ReaR is > > build for and tested on nearly all distros), but I recently found out > that > > on Ubuntu 23.04 this fails like this: > > > > # rm -Rf /tmp/f && mkdir /tmp/f && cp --verbose -t /tmp/f -L > --preserve=all > > --parents /etc/apt/sources.list && echo yes ; ls -lR > > /tmp/f/etc/apt/sources.list > > /etc/apt/sources.list > > /etc -> /tmp/f/etc > > /etc/apt -> /tmp/f/etc/apt > > '/etc/apt/sources.list' -> '/tmp/f/etc/apt/sources.list' > > cp: ‘etc/apt’: No such file or directory > > -rw-r--r-- 1 root root 2437 Apr 23 09:53 /etc/apt/sources.list > > -rw-r--r-- 1 root root 2437 Apr 23 09:53 /tmp/f/etc/apt/sources.list > > # > > > > Ubuntu 23.04 uses cp (GNU coreutils) 9.1 > > > > On Ubuntu 22.04 there is cp (GNU coreutils) 8.32 and the same example > works > > as expected: > > > > # rm -Rf /tmp/f && mkdir /tmp/f && cp --verbose -t /tmp/f -L > --preserve=all > > --parents /etc/apt/sources.list && echo yes ; ls -lR > > /tmp/f/etc/apt/sources.list /etc/apt/sources.list > > /etc -> /tmp/f/etc > > /etc/apt -> /tmp/f/etc/apt > > '/etc/apt/sources.list' -> '/tmp/f/etc/apt/sources.list' > > yes > > -rw-r--r-- 1 root root 263 Mär 26 15:20 /etc/apt/sources.list > > -rw-r--r-- 1 root root 263 Mär 26 15:20 /tmp/f/etc/apt/sources.list > > # > > > > BTW, I checked also on many other distros that ReaR supports and all > > distros with cp version 9.1 fail in the same way. > > > > Can you please have a look and advise how to proceed? We at the ReaR > > project can of course change our code to use tar for example, but I won't > > be surprised if other users will also meet this changed behaviour and > maybe > > it is indeed a bug. > > Looks like a bug indeed. > The attached patch should address this in coreutils. > Any deployments of coreutils 9.1-9.3 inclusive would need to apply this. > > thanks, > Pádraig >
bug#63245: Potential regression: cp --preserve=mode or --preserve=all fails to copy files from subdirectory
On 03/05/2023 10:27, Schlomo Schapiro wrote:
Hello,
I'm a maintainer of the Relax-and-Recover (https://relax-and-recover.org/)
Open Source project and think that I might have found a major regression in
cp, starting somewhere with version 9.
Please see https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/2017414
and https://github.com/rear/rear/issues/2972 for how I found out about this.
Problem:
We use a cp call like the following to copy various files and directory
into a destination path with preserving the structure:
cp --verbose -t DESTINATION -L --preserve=all --parents SOURCE...
Over the last 10+ years that worked well on all Linux distros (ReaR is
build for and tested on nearly all distros), but I recently found out that
on Ubuntu 23.04 this fails like this:
# rm -Rf /tmp/f && mkdir /tmp/f && cp --verbose -t /tmp/f -L --preserve=all
--parents /etc/apt/sources.list && echo yes ; ls -lR
/tmp/f/etc/apt/sources.list
/etc/apt/sources.list
/etc -> /tmp/f/etc
/etc/apt -> /tmp/f/etc/apt
'/etc/apt/sources.list' -> '/tmp/f/etc/apt/sources.list'
cp: ‘etc/apt’: No such file or directory
-rw-r--r-- 1 root root 2437 Apr 23 09:53 /etc/apt/sources.list
-rw-r--r-- 1 root root 2437 Apr 23 09:53 /tmp/f/etc/apt/sources.list
#
Ubuntu 23.04 uses cp (GNU coreutils) 9.1
On Ubuntu 22.04 there is cp (GNU coreutils) 8.32 and the same example works
as expected:
# rm -Rf /tmp/f && mkdir /tmp/f && cp --verbose -t /tmp/f -L --preserve=all
--parents /etc/apt/sources.list && echo yes ; ls -lR
/tmp/f/etc/apt/sources.list /etc/apt/sources.list
/etc -> /tmp/f/etc
/etc/apt -> /tmp/f/etc/apt
'/etc/apt/sources.list' -> '/tmp/f/etc/apt/sources.list'
yes
-rw-r--r-- 1 root root 263 Mär 26 15:20 /etc/apt/sources.list
-rw-r--r-- 1 root root 263 Mär 26 15:20 /tmp/f/etc/apt/sources.list
#
BTW, I checked also on many other distros that ReaR supports and all
distros with cp version 9.1 fail in the same way.
Can you please have a look and advise how to proceed? We at the ReaR
project can of course change our code to use tar for example, but I won't
be surprised if other users will also meet this changed behaviour and maybe
it is indeed a bug.
Looks like a bug indeed.
The attached patch should address this in coreutils.
Any deployments of coreutils 9.1-9.3 inclusive would need to apply this.
thanks,
Pádraig
From 8ad4a486fe03203e00f31262cd106e58385da0f6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?=
Date: Wed, 3 May 2023 17:01:37 +0100
Subject: [PATCH] cp: -p --parents: fix failure to preserve permissions for
absolute paths
* src/cp.c (re_protect): Ensure copy_acl() is passed an absolute path.
* tests/cp/cp-parents.sh: Add a test case.
* NEWS: Mention the bug.
Fixes https://bugs.gnu.org/63245
---
NEWS | 4
src/cp.c | 16 +++-
tests/cp/cp-parents.sh | 6 ++
3 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/NEWS b/NEWS
index 3d34a1b3c..9fad8a775 100644
--- a/NEWS
+++ b/NEWS
@@ -4,6 +4,10 @@ GNU coreutils NEWS-*- outline -*-
** Bug fixes
+ cp --parents again succeeds to preserve mode for absolute directories.
+ Previously it would have failed with a "No such file or directory" error.
+ [bug introduced in coreutils-9.1]
+
cksum again diagnoses read errors in its default CRC32 mode.
[bug introduced in coreutils-9.0]
diff --git a/src/cp.c b/src/cp.c
index 488770a0b..00a5cb813 100644
--- a/src/cp.c
+++ b/src/cp.c
@@ -296,15 +296,19 @@ regular file.\n\
when done. */
static bool
-re_protect (char const *const_dst_name, int dst_dirfd, char const *dst_relname,
+re_protect (char const *const_dst_name, int dst_dirfd, char const *dst_fullname,
struct dir_attr *attr_list, const struct cp_options *x)
{
struct dir_attr *p;
char *dst_name; /* A copy of CONST_DST_NAME we can change. */
- char *src_name; /* The source name in 'dst_name'. */
+ char *src_name; /* The relative source name in 'dst_name'. */
+ char *full_src_name; /* The full source name in 'dst_name'. */
ASSIGN_STRDUPA (dst_name, const_dst_name);
- src_name = dst_name + (dst_relname - const_dst_name);
+ full_src_name = dst_name + (dst_fullname - const_dst_name);
+ src_name = full_src_name;
+ while (*src_name == '/')
+src_name++;
for (p = attr_list; p; p = p->next)
{
@@ -347,7 +351,7 @@ re_protect (char const *const_dst_name, int dst_dirfd, char const *dst_relname,
if (x->preserve_mode)
{
- if (copy_acl (src_name, -1, dst_name, -1, p->st.st_mode) != 0)
+ if (copy_acl (full_src_name, -1, dst_name, -1, p->st.st_mode) != 0)
return false;
}
else if (p->restore_mode)
@@ -687,6 +691,7 @@ do_copy (int n_files, char **file, char const *target_directory,
bool parent_exists = true; /* True if dir_name (dst_name) exists. */
struct dir_attr *attr_list;
char *arg_in_concat = NULL;
+ char
bug#63245: Potential regression: cp --preserve=mode or --preserve=all fails to copy files from subdirectory
Hello, I'm a maintainer of the Relax-and-Recover (https://relax-and-recover.org/) Open Source project and think that I might have found a major regression in cp, starting somewhere with version 9. Please see https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/2017414 and https://github.com/rear/rear/issues/2972 for how I found out about this. Problem: We use a cp call like the following to copy various files and directory into a destination path with preserving the structure: cp --verbose -t DESTINATION -L --preserve=all --parents SOURCE... Over the last 10+ years that worked well on all Linux distros (ReaR is build for and tested on nearly all distros), but I recently found out that on Ubuntu 23.04 this fails like this: # rm -Rf /tmp/f && mkdir /tmp/f && cp --verbose -t /tmp/f -L --preserve=all --parents /etc/apt/sources.list && echo yes ; ls -lR /tmp/f/etc/apt/sources.list /etc/apt/sources.list /etc -> /tmp/f/etc /etc/apt -> /tmp/f/etc/apt '/etc/apt/sources.list' -> '/tmp/f/etc/apt/sources.list' cp: ‘etc/apt’: No such file or directory -rw-r--r-- 1 root root 2437 Apr 23 09:53 /etc/apt/sources.list -rw-r--r-- 1 root root 2437 Apr 23 09:53 /tmp/f/etc/apt/sources.list # Ubuntu 23.04 uses cp (GNU coreutils) 9.1 On Ubuntu 22.04 there is cp (GNU coreutils) 8.32 and the same example works as expected: # rm -Rf /tmp/f && mkdir /tmp/f && cp --verbose -t /tmp/f -L --preserve=all --parents /etc/apt/sources.list && echo yes ; ls -lR /tmp/f/etc/apt/sources.list /etc/apt/sources.list /etc -> /tmp/f/etc /etc/apt -> /tmp/f/etc/apt '/etc/apt/sources.list' -> '/tmp/f/etc/apt/sources.list' yes -rw-r--r-- 1 root root 263 Mär 26 15:20 /etc/apt/sources.list -rw-r--r-- 1 root root 263 Mär 26 15:20 /tmp/f/etc/apt/sources.list # BTW, I checked also on many other distros that ReaR supports and all distros with cp version 9.1 fail in the same way. Can you please have a look and advise how to proceed? We at the ReaR project can of course change our code to use tar for example, but I won't be surprised if other users will also meet this changed behaviour and maybe it is indeed a bug. Kind regards, Schlomo Schapiro
