XPost: aus.computers   
   From: none@not.here   
      
   Axel wrote:   
   > Paul wrote:   
   >> On Sat, 12/20/2025 12:03 AM, Axel wrote:   
   >>> Lawrence D’Oliveiro wrote:   
   >>>> On Sat, 20 Dec 2025 11:42:19 +1100, Axel wrote:   
   >>>>   
   >>>>> Lawrence D’Oliveiro wrote:   
   >>>>>> On Sat, 20 Dec 2025 09:45:57 +1100, Axel wrote:   
   >>>>>>   
   >>>>>>> Lawrence D’Oliveiro wrote:   
   >>>>>>>> On Fri, 19 Dec 2025 07:32:04 -0500, Paul wrote:   
   >>>>>>>>   
   >>>>>>>>> That could be a bad SATA cable (or less likely, a bad SATA port   
   >>>>>>>>> on the motherboard).   
   >>>>>>>>>   
   >>>>>>>> File corruption would have been picked up by an rsync   
   >>>>>>>> verification pass.   
   >>>>>>>>   
   >>>>>>> I did get "copied with errors" messages at times, so then I would   
   >>>>>>> copy each folder or file within the folder one by one and that   
   >>>>>>> fixed it   
   >>>>>> Did you verify the copies afterwards?   
   >>>>> yes. by byte count   
   >>>> That’s pretty useless. No hashes?   
   >>> ???   
   >>>   
   >> Let us make two files   
   >>   
   >> AAAAAABBBBCC   
   >>   
   >> AAAAAABBBBCD   
   >>   
   >> They both have the same byte count.   
   >>   
   >> Now, do   
   >>   
   >>     sha256sum file1   
   >>     sha256sum file2   
   >>   
   >> and the checksums are entirely different. This is also termed "using   
   >> hashes".   
   >>   
   >> It's why hashdeep was invented. Hashdeep can generate checksums   
   >> for all the files in a source tree, then be used to audit   
   >> the same files in a destination tree.   
   >>   
   >>     sudo apt install hashdeep   
   >>   
   >>     cd /home/felix   
   >>   
   >>     hashdeep -c md5 -j0 -r Downloads > /tmp/audit.txt   # Source tree   
   >> is /home/felix/Downloads   
   >>                                  
   Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â  # It has our   
   >> Golden Files.   
   >>   
   >>     # The path value might be relative or absolute, and the reason   
   >>     # I am using the crafty "cd" values is to be able to audit a   
   >>     # relative path thing for identical contents. both recursive -r   
   >>     # point to the same "directory name".   
   >>   
   >>     cd /media/mint/WDBLUE       # The copied files we hope are the   
   same.   
   >>                                 # This is   
   the destination we wish to   
   >> audit for corruption.   
   >>                                 # The   
   destination is our potentially   
   >> unreliable copy as   
   >>                                 #   
   /media/mint/WDBLUE/Downloads we did   
   >> with our rsync.   
   >>   
   >>     hashdeep -c md5 -j0  -k /tmp/audit.txt -a -v -v -r Downloads >   
   >> /tmp/audit-out.txt   
   >>   
   >> The "md5" is the fastest hash supported by hashdeep.   
   >> The -j0 means "run the audit on a single thread as this is a hard drive   
   >>                 and we really want the file list to be in   
   predictable   
   >> order".   
   >> The -k specifies an audit file to compare against.   
   >> The -a is "audit mode" and it expects -k to identify the audit file   
   >> to use.   
   >> The double verbose makes the output verbose   
   >> The -r is for recursive descent below the Downloads tree.   
   >> The audit-out.txt should identify destination files with a problem.   
   >>   
   >> That's the basic idea, but you can easily "fall into a hole"   
   >> while using hashdeep, and it requires a good deal of hand holding.   
   >> (I use this on both Windows and Linux.) You should open both "audit.txt"   
   >> and "audit-out.txt" with a text editor and make sure the right things   
   >> happened.   
   >>   
   >> There are more utilities than this, for comparing file trees.   
   >> "Tripwire" would be an example of an old one.   
   >   
   > I'm making progress on the file transfer problem and will post soon.  :)   
   > also I found an app called Meld for checking folders   
   >   
      
   So the sad tale thus far. But first, some detail. This PC (specs below)   
   has LM 22.2 installed on a 1Tb NVME. It also has two mobile racks for   
   easy insertion and removal of HD's. The lower rack I use for the   
   Timeshift disk, and the upper one for the files disk, a WD 1Tb   
   mechanical disk formatted in Ext4. It also has two external USB cases   
   for additional hard drives. Following a process of trial and error, I've   
   discovered that the problem of file errors only occurs when I write to   
   the files disk in the mobile rack. I can read/write both ways NVME to   
   USB without errors, and read/write both ways USB to USB without errors.   
   I can also read from the files disk to write to either USB without   
   errors. So my trouble shooting has been focused on the mobile rack.  I   
   replaced it, and also the cable, and swapped the cable to another   
   motherboard (MB) SATA port. Since USB transfers work, and the USB boxes   
   have their own power supply, I thought maybe it was a power issue within   
   the PC. According to the newegg calculator   
   [https://promotions.newegg.com/tools/power-supply-calculator/v2/ ] I   
   need 600 -700 watts for this PC. The PS was only 550 watts so I swapped   
   it out with a 750 watt PS. Having said all this, I can write to the   
   Files disk if I transfer folders/files in small lots of up to about   
   10Gb, and today I tried an old 320 Gb NTFS HD in the rack, and I could   
   write to it without limitation. ??? This is a really confusing for me.   
   I've lost track of what's been suggested to do so far, and I don't know   
   what to try next, since I've run out of ideas. :(   
      
   AMD Ryzen 5 5500|16 Gb RAM|1Tb NVME|NVIDIA GeForce GT 1030   
      
      
   >>   
   >>      Paul   
      
      
   --   
   Linux Mint 22.2   
   {I shot Felix and buried him}   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)