Subject: bug#46815: closed (Re: bug#46815: cp integer overflow in progress (time remaining))

From: [email-masked] (GNU bug Tracking System)
Date: Sat, 27 Feb 2021 17:55:02 +0000

Your bug report

#46815: cp integer overflow in progress (time remaining)

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].

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

Subject: Re: bug#46815: cp integer overflow in progress (time remaining)
From: Paul Eggert <[email-masked]>
To: Ronald Knol <[email-masked]>
Cc: [email-masked]
Date: Sat, 27 Feb 2021 09:54:26 -0800
List-Id: <debbugs-submit.debbugs.gnu.org>

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.

Subject: cp integer overflow in progress (time remaining)
From: Ronald Knol <[email-masked]>
To: [email-masked]
Date: Sat, 27 Feb 2021 07:35:38 -0800
List-Id: <debbugs-submit.debbugs.gnu.org>

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.