GNU bug report logs - #60455
Missing fallback if copy_file_range returns ENOENT?

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Pádraig Brady <P <at> draigBrady.com>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#60455: closed (Missing fallback if copy_file_range returns
 ENOENT?)
Date: Sun, 08 Jan 2023 13:46:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Sun, 8 Jan 2023 13:45:40 +0000
with message-id <daa4c1cd-b01b-92b2-7e04-e0fed9650852 <at> draigBrady.com>
and subject line Re: bug#60455: Missing fallback if copy_file_range returns ENOENT?
has caused the debbugs.gnu.org bug report #60455,
regarding Missing fallback if copy_file_range returns ENOENT?
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
60455: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=60455
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Sam James <sam <at> gentoo.org>
To: bug-coreutils <at> gnu.org
Subject: Missing fallback if copy_file_range returns ENOENT?
Date: Sat, 31 Dec 2022 17:00:48 +0000

[Message part 3 (text/plain, inline)]

Hi folks,

Originally reported in Gentoo at https://bugs.gentoo.org/885793.

Frank Limpert reported that when copying large files across CIFS shares,
cp may abort because copy_file_range returns ENOENT sometimes.

This sounds like a suspicious kernel bug if CIFS interactions are sometimes
spuriously giving ENOENT, but I'm wondering if coreutils needs to do
anything to handle this as well.

strace output from his cp invocation: https://bugs.gentoo.org/attachment.cgi?id=842497

Best,
sam

[signature.asc (application/pgp-signature, attachment)]

[Message part 5 (message/rfc822, inline)]

From: Pádraig Brady <P <at> draigBrady.com>
To: Sam James <sam <at> gentoo.org>
Cc: 60455-done <at> debbugs.gnu.org
Subject: Re: bug#60455: Missing fallback if copy_file_range returns ENOENT?
Date: Sun, 8 Jan 2023 13:45:40 +0000

On 08/01/2023 00:51, Sam James wrote:
> 
> 
>> On 7 Jan 2023, at 16:25, Pádraig Brady <P <at> draigBrady.com> wrote:

>> OK it's probably worth handling in coreutils then.
>> Note I still get the feeling this is a race in CIFS
>> that is only being made more apparent with copy_file_range(),
>> but fair enough that this is a regressions for users and
>> we should be able to cater for it easy enough.

Or more precisely, ENOENT will be unusual for fd operations,
and so falling back to a standard copy should just be
restricted to this or similar cases.

If this was seen on a single CIFS mount it may be
less appropriate as then the user may not want to
fall back to a client side copy, when a server side should work.
But in this separate mount case, the fallback is appropriate.
I guess we could restrict to separate device IDs,
but that's probably getting too complicated for this.

> Total agreement. Thanks, looks good!

Pushed.
Marking this as done.

cheers,
Pádraig

Previous Next

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