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

Previous Next

Full log

View this message in rfc822 format

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

[Message part 1 (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 2 (text/html, inline)]

Previous Next

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