XPost: aus.computers   
   From: none@not.here   
      
   Paul wrote:   
   > On Tue, 12/23/2025 2:45 AM, Axel wrote:   
   >> 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.   
      
   I've also tested the RAM using memtester   
      
   >>   
   >> 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   
   > In reverse order, you should not start by fretting about power. I have a   
   > "Kill-o-Watt" meter, and it is currently connected to the Daily Driver.   
   > It shows 36 watts right now, as I type.   
   >   
   > The power calculation is a worst case. Maybe it assumes Prime95 running at   
   > the same time as Furmark (graphics burn-in program) are running. in other   
   words,   
   > everything pushed to the wall. While you are doing the file copy test,   
   > things are not pushed to the wall.   
   >   
   > The processor is 64W (turbo or railing at ~130W maybe).   
   > The GT1030 is maybe 40W or so (It has no PCIe 2x3 or 2x4, and 60W is   
   > a rough max for a typical video card of that nature).   
   >   
   > You're not even remotely close to 550W, by analyzing the first   
   > consumers that come to mind. General motherboard power, we award   
   > 50W as a random choice. Now, you're at 220W or so on a max-test.   
   >   
   > You can check the voltages, +3.3V, +5V, +12V ad see if they   
   > are "wilting" and approaching the -5% level. 5V and 12V can be   
   > measured on a Molex 1x4.   
   >   
   > But just in general terms, unless the computer crashes once an   
   > hour while you're trying to use it, chances are the PSU is not   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)