Hacker News new | ask | show | jobs
by jofla_net 99 days ago
Buyer be warned i think this is extremely brand-dependent.

While i've had generally solid experience with sandisk for almost 20 years and had a few old drives (which i hear are slc-based so its not surprising) hold files for over 5 years no issue, i recently almost lost over 4 years of photos.

I had purchased some lexar drives from costco since they were dual interface (usb A / usb C) about 2 years ago, and it was usefull to just get some pictures off my phone. I usually don't rely on such a setup for long term but as with all things I was delayed tending to it. I figured there were 2 per box so i just copied them twice, and diffed them several times to make sure they were exact copies.

After 24 months, one of the drives had a %95 loss, almost every picture was lost cut-off bottom half or so. The other drive surprisingly seemed fine, though it had been plugged in every 6-9 months I recall, as I wanted to browse it a few times, it seems that this action saved the volume. Upon further inspection the good drive still lost 10 pictures in about 5 thousand, so it wasn't perfect.

Lexar.

https://www.ebay.com/itm/176810492981?chn=ps&_trkparms=ispr%...

4 comments

> After 24 months, one of the drives had a %95 loss, almost every picture was lost cut-off bottom half or so.

If these are JPEGs with a grey or green lower half, it's likely only a few 16x16 macroblocks are corrupted and you can recover the rest.

This cannot be done programmatically because you have to guess what the average colour of the block was, but it can be worth it for precious pictures.

This is one of the reasons I like the PNG format - it has checksums. You can fix a surprising number of broken files by bruteforce testing plausible errors until the checksum passes.

With JPEG one of the big problems is that the data is Huffman-encoded without any inter-block markers (except maybe Restart Markers, if you're lucky). This means that a single bitflip can result in a code changing length, causing frameshifts in many subsequent blocks and rendering them all undecodable. If you have a large block of missing data (e.g. a 4k-byte sector of zeros), then you have to guess where in the image the bitstream resumes, in addition to guessing the value of the running DC components.

It's surprising that it can't be done programmatically, since "minimize the color difference above and below this super obvious line" seems like it should be a pretty straightforward success criterion.
AI may be the “killer app,” for these kinds of “back up and squint” judgment calls.
yes they were grey
To pile up another anecdote: late in 2018 I put a well used PC with an Intel SSDSCKKW240H6 (240GB SSD in M.2 form factor) in storage and picked it up 5 years later. The SSD was unreadable then. The PC (with a different storage system) still runs (sans the fan-control, which apparently took a beating on first boot after such long dormancy and the CMOS battery is meanwhile depleted).
Really who knows if you're getting a legit drive any longer...

https://www.tomshardware.com/pc-components/ssds/fake-samsung...

Well I just ordered a drive from sandisk.com, hopefully they’re not mailing out counterfeits.
Could it possibly be that it wasn't the drive, but maybe the import application?

https://news.ycombinator.com/item?id=45274277 (Apple Photos corrupts images on import - images truncated)

it was linux,

i either copied them with $cp -ar or $rsync -a

then distinctly remembered diffing each drive against each other with $diff -qr <drive1> <drive2>