bug#46815: cp integer overflow in progress (time remaining)
On 2/27/21 1:31 PM, Ronald Knol wrote: I am looking at "src/cp.c" from coreutils-8.32 and it has command line options --progress-bar (aka -g). coreutils-8.32 doesn't have those options. Apparently you have a modified copy. You can verify this by getting the original from: https://ftp.gnu.org/gnu/coreutils/coreutils-8.32.tar.gz It would have saved time for both of us if the people who modified your copy had changed the package name and bug-reporting address. Once you find out who modified your copy, please suggest that to them.
bug#46815: cp integer overflow in progress (time remaining)
On 2/27/21 7:35 AM, Ronald Knol wrote: This is "cp -argu ". 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.
bug#46815: cp integer overflow in progress (time remaining)
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 ". 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.
