XPost: aus.computers   
   From: nospam@needed.invalid   
      
   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.   
   >   
   > 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   
   faulty. If puffs of smoke come from the PSU, it smells funny,   
   unless there are reasons to suspect it, that isn't it.   
      
   *******   
      
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)