GNU bug report logs - #46815
cp integer overflow in progress (time remaining)

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#46815: closed (cp integer overflow in progress (time remaining))
Date: Sat, 27 Feb 2021 17:55:02 +0000

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

Your message dated Sat, 27 Feb 2021 09:54:26 -0800
with message-id <a24c452d-77ab-1ed0-fba1-4f93bc4ed002 <at> cs.ucla.edu>
and subject line Re: bug#46815: cp integer overflow in progress (time remaining)
has caused the debbugs.gnu.org bug report #46815,
regarding cp integer overflow in progress (time remaining)
to be marked as done.

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


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

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

From: Ronald Knol <rwjknol <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: cp integer overflow in progress (time remaining)
Date: Sat, 27 Feb 2021 07:35:38 -0800

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

cp (GNU coreutils) 8.32
CentOS Linux release 7.4.1708 (Core)
kernel 3.10.0-693.17.1.el7.x86_64

I have identified an issue with "cp" where, if more than 2 TiB of data is
being copied, and progress reporting is on, after 2 TiB has been copied the
time remaining overflows.

The output goes like this:

728 files copied so far...                                   2.0 TiB /
4.9 TiB
[============================>                                          ]
41.0 %
Copying at 206.2 MiB/s (about 4h 25m 44s remaining)
...127TE.RDM/A018_A007_0127H2.RDC/A018_A007_0127H2_004.R3D   1.6 GiB /
3.8 GiB
[=============================>                                         ]
42.1 %
728 files copied so far...                                   2.0 TiB /
4.9 TiB
[============================>                                          ]
41.0 %
Copying at 203.1 MiB/s (about 4294967286h 4294967261m 4294967249s remaining)
...127TE.RDM/A018_A007_0127H2.RDC/A018_A007_0127H2_004.R3D   1.7 GiB /
3.8 GiB
[===============================>                                       ]
44.7 %

This is "cp -argu <sourcedir> <destdir>". The source tree contains more
than 2TiB worth of data.

I believe the issue is in src/copy.c where (on line 355) an INT is used to
store "cur_size".

    int cur_size = g_iTotalWritten + *total_n_read / 1024;

When dealing with filesizes and capacities, the largest possible type
should be used, which I believe is a unsigned long long (or __uint64_t).

Note that I also think that usec_elapsed and sec_elapsed should be larger
types than int and double to prevent overflows.

[Message part 4 (text/html, inline)]

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Ronald Knol <rwjknol <at> gmail.com>
Cc: 46815-done <at> debbugs.gnu.org
Subject: Re: bug#46815: cp integer overflow in progress (time remaining)
Date: Sat, 27 Feb 2021 09:54:26 -0800

On 2/27/21 7:35 AM, Ronald Knol wrote:
> This is "cp -argu <sourcedir> <destdir>". The source tree contains more
> than 2TiB worth of data.
> 
> I believe the issue is in src/copy.c where (on line 355) an INT is used to
> store "cur_size".
> 
>      int cur_size = g_iTotalWritten + *total_n_read / 1024;

GNU coreutils 'cp' lacks a 'g' option, and doesn't have the line number 
you mentioned. It sounds like you're dealing with a bug in a modified 
version of 'cp', which means you should direct your bug report to 
whoever made that modification.

Previous Next

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