Retrieved the data from the laptop drive and am now copying that data to the server as Unsorted.
Will leave a note at that directory regarding the new directory and the existing three: that some of the files have different checksums during transfer in 2021 (what we know so far, anyway).
I now suspect it was possibly RAM related somehow, as there were no known issues with these disks at that time.
Seems some of Sis's video collection have different file hashes between her old laptop and the file server.
This happened before the NAS upgrade in September 2022, so I can rule out my RAID5 setup there. The original copies are still on the old laptop, so I am retrieving those now. But, something's up with the drive installed in the laptop.
I have since changed the RAM somewhere around April 2023. I have also found out that I can use unbuffered ECC RAM on the ASUS P5N-E SLI board; however, it may not actually use ECC on the system.
Finally changing some main paths. Historically, USB drives had a /media directory on Ubuntu; for some reason, hard disks would use this as well. These are finally phased out on this server and will use /mnt as usual.
Seen this behavior on a suspect hard drive with pending bad sectors in August 2021: on a test Windows XP install using a suspect Seagate 320GB HDD, I copied a large archive to the NAS, then I copied that file to the test system. On the test system, the file was corrupt, even after a few retried copy attempts from the NAS. Of course, on the NAS, it was perfectly fine; hashes matched the one on the laptop but not on the test system. Final attempt was to copy that file to the test system using a USB stick, and that eventually worked.
Of course, without file system integrity checks, this is the result. I'm just usually very good at catching these so far.
The site data is on a single 2TB drive, while the database is on a mirrored 80GB setup, though the 80GB one will have to be done as software RAID and not nvRAID this time.
I also suspect nvRAID may have a terabyte bug on this old motherboard, so it's better to use software RAID in the long run anyway.
Seems the file corruption issue no longer occurs after these reallocation events as well. I'll keep watch; will have to get a replacement HDD if it gets nearly bad enough.
On another note, my main webserver OS drive (where this very microblogging instance is hosted) actually has 14 reallocated sectors from the original 0 over the years... and the original issue was a stuck UNC that a zero-write cleared (and the bad sector count remained at 0). That was back in October 2011, when the server was migrated to Linux.
* PCB routing mistakes regarding nSRST - fixed
* Potential safety issue between the JTAG header and DC barrel jack - fixed
* via sizes - changed
* identification text labeling - now present
Tested the JTAG circuit again with the first 74HC244. Confirmed: it does not work. Inserted the second 74HC244 in the circuit, and it works perfectly. The first part is known good.
I may have run into the one 74HC244 that does not work with TTL spec so far! 😮 But, this is why I have ordered six of them. This is also a reminder to use the recommended 74HCT244 for the buffered JTAG (Wiggler) circuit instead.
Status of WholeFlash dump using the practically elusive TJTAG 3.0.2.1 (known as EJTAG Debrick Utility v3.0.2.1 Tornado-MOD) with the unit. Took about 38 minutes to dump the entire flash chip on the system.
An issue with this version: On Windows XP (on USP4, not sure on official SP3), upon calculating the elapsed time after the dump is finished, it crashes. But hey, at least you receive your file in the process. http://cwcyrix.nsupdate.info/gnu-social/public/url/30