Recovering videos from my Sony camera that I stupidly deleted | Hacker News Reader

Recovering videos from my Sony camera that I stupidly deleted

jeffgeerling.com

86 pointsspeckx72 comments

My neighbor just did the exact same thing. The way FAT filesystems work is they change the first byte of the filename to an invalid character to make them a tombstone.

Since he hadn't used the SD card yet, we were able to restore the files with "TestDisk", a companion tool that ships with PhotoRec. Under "Advanced" there is an "Undelete" tool. This will let you browse the filesystem, find your missing files, and copy them to another drive.

For those old enough to remember, MSDOS came with undelete.exe which worked the same way.

> For those old enough to remember, MSDOS came with undelete.exe which worked the same way.

Available in MS-DOS >= 5.0. If you had MS-DOS 3.3, you didn't get any cool stuff like that. Couldn't even see hidden files!

Which is why Norton Utilities was so popular.

Years ago, I recovered some pics from my honeymoon this way after we accidentally deleted them because I knew FAT worked this way so I just went looking for them.

I've never felt so happy to be a techie.

Disk Drill saved me last year when file corruption hit one of my SDs.

I also have a policy where I don’t delete the files on the SD card until the very last moment when new files need to be written again. This gives me a window of time in which there is an extra backup in case of issues with replication from my initial local storage on my computer, to an external drive, to the RAID array, or to the cloud.

rm -rf after the initial copy from the SD card onto the computer is a bad idea, especially if the card isn’t immediately needed for new footage.

For convenience, I like to still have the files somehow marked 'already imported', so I've since modified my script to move the files on the card into an 'imported' folder. Then after the card gets full, I'll format it if I'm finished with the main project I'm working on.

I really wish modern cameras could stream over WiFi 6 or 7 (since it's just H.265 compressed, 50-100 Mbps) so I could either do NDI or a video stream off to my NAS. Still save to the card in the body, but also record over the network directly in-body!

I wish too.

Oof, so free software didn’t do the job despite a ton of effort and leveraging a boatload of past experience, and the paid software gave a misleading impression of success before accepting Jeff’s money, only for the actual fix to be buried in a submenu somewhere.

My inner product manager is screaming.

Fairly unsatisfying conclusion. I’d be interested in knowing what that proprietary program does, how it works so well, how Sony stores video files, etc.

I've found when you have a file with stops and starts, it's because the extraction process is not familiar with how the data is laid down on the storage media. So it sees 'I have a file'...and if it's better it sees 'the name of the file is here' and then 'it's this big' and then 'here's the linked list of clusters for that file'....or it starts at the first cluster and gets as far as it can before it runs off the tracks.

The proprietary program has this blog post: https://www.cleverfiles.com/help/advanced-camera-recovery-in...

I think the key point is that cameras don't write the video files in one long contiguous block on disk. They internally split it up and write in an interleaved fashion. It even mentions low-level tricks like manipulating the FAT table so the moov atom which is written last appears at the beginning of the file.

I had never seen Jeff's posts pop up on HN prior to this year and only learned of him via YouTube r/homelab content. Scrolling through the hn search his domain has had plenty of posts over the years, but his content has now become stickier and/or the audience has changed?

He shares the title of "SBC Guy" with ExplainingComputers. Any time a new single-board computer comes out, especially a Raspberry Pi, they make videos with benchmarks etc. etc.

I took too long to write my comment, you beat me to the punch. I didn't plagiarise your comment, but I do largely agree!

He's definitely got brand recognition. He's THE guy for Raspberry Pi and SBC stuff. I'd suspect more people would recognise him then Ebon Upton nowadays. Not ignoring the other stuff he's done, but anyone into Pi/SBC will know him.

Honourable mentions to ExplainingComputers and "Platima Tinkers".

Eben https://en.wikipedia.org/wiki/Eben_Upton

Just got Elonized by you

My sincerest apologies to Eben. I don't know how I flubbed that, as I opened another tab and searched for him so I knew I'd get the spelling of his surname right. A fellow Welshman and everything! I am suitably embarrassed.

I think the main problem here was that there wasn't a single script that:

1. Accepts no parameters.

2. Looks for an SD card with a bunch of Sony-structured folders.

3. Copies the media from that to the NAS folder directly and fsyncs.

4. Checks that the files are there and look ok.

5. Maybe triggers a ZFS snapshot? Why not.

6. Only then deletes the files from the source.

My advice is to have "some fair number" of SD cards and when you are done with the card in the camera, put it aside and install another card that hasn't been used in awhile.

Because managing files is not only error prone, deleting files should be avoided to the extent your budget allows...

...and if you are shooting still (and not video) there's really no good reason to ever delete an image off an SD card because SD cards are cheap (because photos don't require highest speed cards). SD cards can be used as "film" in a digital camera.

Yeah, after working through this blog post, I ordered 6 more cards, so I can have a queue and not delete footage until project completion!

My advice is to run a script that automatically copies the files to the right place rather than hope you have the right window open at the time.

Apple was killing it with iPhoto/Photos for this use case until a few years ago. Put in a memory card and Photos would import new photos, offer to delete after import, and ignore photos still on the card. Photo Stream made it possible to have a minimal set of photos in the cloud to have on other devices, which could be configured to sync various albums.

Then they moved to iCloud or manual sync and your forced to manage individual files again. Delete in iCloud, it’s gone everywhere. Want to keep your bad shots, but not have them on every device? Figure out how to move photos between multiple libraries while only being allowed to have one open at a time.

> Then they moved to iCloud or manual sync and your forced to manage individual files again. Delete in iCloud, it’s gone everywhere. Want to keep your bad shots, but not have them on every device? Figure out how to move photos between multiple libraries while only being allowed to have one open at a time.

I don’t understand that. If you use iCloud, the cloud is primary storage, and your disk caches recently accessed cloud data.

So, just keep everything in a single library, and if your disk fills up iCloud will remove pictures you haven’t accessed recently from your disk.

Some people don’t want to see all their bad shots when scrolling through their library, but they do want to keep them.

> My advice is to have "some fair number" of SD cards and when you are done with the card in the camera, put it aside and install another card that hasn't been used in aw

Yeah, a kind of rotating workflow seems necessary when you doing professional camera stuff.

Of course, something like this can always happen; however, it's just as likely that an SD card will fail at some point.

The camera should record redundantly, and many semi-pro cameras already do this if you want them to. Then you can leave the second card untouched and have a spare one and rotate only the spares.

> because photos don't require highest speed cards

That hypothesis is certainly getting tested these days in specific niches. With high megapixel sensors, pre-capture, and cameras capable of pushing between 30fps and 120fps worth of compressed raws or high quality JPEGs, you can obliterate your camera's write buffer and CFExpress write bandwidth. You can make many bad photos of an animal, bird, or athlete with extreme ease -- and hopefully find that one winner in the haystack.

I would say the line between movies and photos is getting blurred, but it's unlikely you're using a shutter speed that allows for motion blur with these bursts of photos!

> high megapixel sensors, pre-capture, and cameras capable of pushing between 30fps and 120fps worth of compressed raws or high quality JPEGs

Surely those are buffered in the RAM first, then flushed to the card. When the buffer is full, cameras either stop recording or have to flush continuously, which reduces the burst rate.

Yes, that's correct. Buffer sizes are also all over the place, so if you want to shoot continuously, you need to pick carefully. Check https://www.fredmiranda.com/forum/topic/1856860/0 for a thorough analysis starting with the Sony A9iii (which can fill the buffer incredibly quickly with its premier feature, the 120fps 14-bit raw output global shutter). Deeper in the thread compares to the Nikon Z9.

Except unpowered SD cards (and SSDs for that matter) don't claim to hold data for more than a couple of years.

I'm a big believer in thinking you have backups being worse than knowing you don't, so anything that encourages people to believe $(flash memory) is suitable as long-term cold storage is actually, really bad.

I agree there's no need to copy & wipe cards immediately, but treating them as "film" is inherently flawed and setting yourself up for failure. The amount of people that turn up in data recovery forums unable to access old, important, "backed up" (memory card/ssd on a shelf) photos is depressingly high.

> photos don't require highest speed cards

I photograph birds in flight at 25 or 50 FPS.

Even if I didn't do something that demands fast cards and fills them up quickly, I don't see much reason to keep photos on SD cards rather than my laptop's SSD with an external HDD as backup. I import and cull the photos, run a backup, and reformat the cards.

>and if you are shooting still (and not video) there's really no good reason to ever delete an image off an SD card

There are tons of good reasons.

When downloading images off the card, software has to read all the files on it - which can take a very long time if the card is full of photos you've already processed in a previous session.

Then there's that you shouldn't be keeping most of the shots you take. Unless you're a still life artiste, most people (including professionals) take multiple pictures to account for blinking, moving objects, slightly different angles, etc. You should keep the best shots and delete the rest - storage is cheap but having to go back through all the garbage to find the good shots in the future is pointless.

Modern cameras have large sensors that produce large files. It's wasteful to keep buying more and more SSD cards. Just build a NAS or pay for cloud storage.

Nothing worse than getting footage ingest underway and discovering the card has all kinds of stuff on it already that you now need to audit

Library software typically avoids that.

It doesn't avoid the delays. I have incredibly fast CFx cards, an incredibly fast card reader, and an incredibly fast CPU in my desktop, but the simple reality is that reading tens (or hundreds) of gigabytes over USB takes a long time, and analyzing those files to determine if they're already in my large photo library takes a lot of resources too. Minutes, not milliseconds.

A RAW file from a Nikon Z8 is generally 50-70MB. If I left 300 photos on the card before going out for a shoot, that's tens of gigabytes of data to transfer and analyze before the software can get to the images I'm actually interested in. If it's hundreds of gigabytes the problem is even worse.

Then we can go the other direction. Popping a partially full card in my camera with media that I can’t sort through at a glance/quickly. Library software isn’t going to help you there.

Best practice is to dump, back up, and format. If you’re doing photos and you’re not shooting several gigs per shot hundreds of times then sure you can hold onto those SD cards, but then you need to take them out of rotation.

Ultimately boils down to the kind of user we are talking about, which is incredibly varied

Fun and useful fact - if you ever buy a Sandisk SD card, there is a license key for RescuePRO Deluxe inside if you peel apart the two pieces of the cardboard that make the packaging! The software works for any type of drive and I have had great luck with it recovering some of my students projects.

Lucky for him it was a Sony. Thanks to Android 10 and file encryption on every file, it is now impossible to restore deleted videos/pictures/files on any Android device:

https://security.stackexchange.com/questions/264642/are-andr...

Considering the amount of personal data on people’s phones, plus how commonly people lose them in public, I would say that encryption by default is unambiguously a good thing, and it’s incredible that it took Google until Android 10.

Encryption by default doesn’t require disabling undelete.

Camera makers: please just use Android and allow us to sync photos automatically.

You don't need Android for that (thank god).

How would you upload to Immich?

Using their extensively documented restful API is the most obvious option to me: https://api.immich.app/endpoints

I mean, yes. But how would you put the code that utilizes this API onto the camera?

Ah. I didn't realize you were looking to install arbitrary android apps on a camera.

That does exist. Samsung used to make android interchangeable lens cameras, and now Yongnuo does.

I owned that Samsung camera (Samsung Galaxy Camera)! Samsung made ONE model and then abandoned it.

It was awesome for its time, I could make pictures at a party, upload them to Picassa right away, and share them with a friend. It had a GPS receiver (a thing that cameras STIL!!!!! lack) so I had automatic geotagging.

I tried to get YN455, but they don't sell them in the US and apparently it doesn't even have proper English localization. I do speak some Mandarin, but I still want something localized.

You can pair the camera with your Android phone and use that to do whatever.

But also, manufacturers could do apps and support APIs without adding a whole Android OS with all the downsides that it entails.

But maybe we're talking about different kind of cameras.

I have never seen camera that actually did anything useful with the pairing mode. It's inevitably buggy and useless, also requiring a manufacturer's app on the phone.

That's why it's _still_ easier to just pop the SD-card and copy files. So even Apple had to add the SD slot back to Mac Books.

I agree, but your camera doesn't currently have Android either, so you're comparing current situation to what could be. The manufacturers could fix the bugs and make pairing more useful. I'd rather have manufacturers app on my phone than Android on my camera.

There were cameras with FTP or WebDAV support, when connected to WiFi. I guess it’s just not really popular?

I don't think I've seen one that actually worked. The closest one was a third-party app for a Sony camera that used the Picassa/Google Photos API.

Those always existed but I suspect it's for some highly specific business use cases, something like fashion magazine photo studios or some R&D facility infra. They're not for reliably syncing photos over the Internet.

Or maybe it's just the matter of someone writing a single executable installer to set up the host for those but I don't know...

First part hell no second part hell yeah. I wouldn't want to deal with current equivalent of Android 2.3 or 4.0.4 or eMMC failures or 5 minute bootup delay from battery insertion to first shutters with high end $1.5k cameras.

What's needed is USB-C host on iPhone. Then USB MTP or MSC to extract and upload. Which, is arguably already there. I think what's really missing is iOS/Android side willingness to ingest offline files.

You can have instant Android with suspend-to-RAM. My Galaxy camera did that in 2012. And the cold boot took something like 12 seconds.

And I've seen modern Android devices cold-boot in 2 seconds.

Ironically, Android started as a DSLR OS.

Honestly hat read for me as "Disk Drill" ad.

Reply on news.ycombinator.com