Subject: bug#63245: closed (Re: bug#63245: Potential regression: cp --preserve=mode or --preserve=all fails to copy files from subdirectory)

From: [email-masked] (GNU bug Tracking System)
Date: Thu, 04 May 2023 22:30:03 +0000

Your bug report

#63245: Potential regression: cp --preserve=mode or --preserve=all fails to copy files from subdirectory

which was filed against the coreutils package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
63245: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63245
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#63245: Potential regression: cp --preserve=mode or --preserve=all fails to copy files from subdirectory
From: Pádraig Brady <[email-masked]>
To: Schlomo Schapiro <[email-masked]>
Cc: [email-masked], Kamil Dudka <[email-masked]>, Michael Stone <[email-masked]>
Date: Thu, 4 May 2023 23:29:16 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

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

Subject: Potential regression: cp --preserve=mode or --preserve=all fails to copy files from subdirectory
From: Schlomo Schapiro <[email-masked]>
To: [email-masked]
Date: Wed, 3 May 2023 11:27:01 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

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