bug#69535: Problem with copying an EXTREMELY large file - cmp finds a mismatch

[Brian]

I don't know whether the problem I've found is with cp or with cmp, so 
I don't know whether to address this report to coreutils or diffutils. 
If you think I've guessed wrong, please tell me so.


I am trying to make a backup copy of a very large (40 Gigabyte) data 
file - yes, I have plenty of disk space! :) It's a binary file, 200 
byte fixed length records to be precise, not a text file. I have 
downloaded, compiled and used the latest versions of cp and cmp and 
the problem persists. My system is a 16-core AMD Ryzen desktop running 
Linux Mint 21.3.


The steps to reproduce the problem are simple, provided you have the 
data file!


I have a folder called original in the data directory. From a terminal 
prompt, I run


cp data.dat original

this apparently completes correctly - at least, no error messages are seen

I then run

cmp -l data.dat original/data.dat

and I get something around 100 bytes of differences. On the basis of 
three attempted copy and comparison pairs, the addresses of these 
differences vary, but they're always a single block of contiguous 
locations, and always towards the end of the file (the last time, they 
were in the 35,000,000,000s).


I have run a fsck on the drive (a 14 TB Seagate connected to one of 
the motherboard SATA ports) and no problems were found.


Any advice, please? I'm close to the limits of my debugging knowledge.

Please note that I have absolutely zero knowledge of the C language or 
its derivatives. I'm a (retired) scientist turned database programmer, 
I know Pascal, FORTRAN and SQL, and that's about it.



Thanks,

Brian.

bug#69532: mv's new -x option should be made orthogonal to -t/-T/default

[Paul Eggert]

Although I like the idea of exposing file swaps to the user, the first 
cut of 'mv -x' has significant problems.


I expect 'mv -x A B' to act like 'mv A B' except the destination must 
exist and is renamed back to A. However, this is not true for 'mv -x A 
B' when B is a directory; it renames B to A rather than renaming B/A to 
A as I expect. That is, 'mv -x' acts as if -T (--no-target-directory) is 
also specified. There is no way to get mv's traditional behavior, or to 
get mv -t behavior.


To fix this, 'mv -x' should respect the usual mv behavior with respect 
to directories. For example, when D is a directory 'mv -x A B C D' 
should act like 'mv A B C D' except that D's old entries should be 
renamed back to A B and C. And the -t and -T options should work with -x 
the same way they work when -x is not specified.


This needs to happen before the next coreutils release, to avoid 
confusion about 'mv -x'.