<?xml version="1.0" encoding="UTF-8"?>
<oembed>
 <version>1.0</version>
 <type>link</type>
 <provider_name>Ami Sapphire's Notices</provider_name>
 <provider_url>http://cwcyrix.nsupdate.info/gnu-social/public/</provider_url>
 <title>Clarissa Walker (amisapphire@cwcyrix.nsupdate.info)'s status on Tuesday, 27-Jun-2023 22:21:43 EDT</title>
 <author_name>Clarissa Walker (amisapphire@cwcyrix.nsupdate.info)</author_name>
 <author_url>http://cwcyrix.nsupdate.info/gnu-social/public/index.php/amisapphire</author_url>
 <url>http://cwcyrix.nsupdate.info/gnu-social/public/notice/110</url>
 <html>Going through the older 2TB storage drives and comparing some of the data with the current NAS data, it is safe to assume the data corruption event started around mid-March 2023 and ended around early April 2023, months after the September 2022 upgrade. May 2023 is when the bad sectors were reallocated.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Of course, without file system integrity checks, this is the result. I'm just usually very good at catching these so far.</html>
</oembed>
