How Frogger 2’s source code was recovered from a destroyed tape [video]

8 months ago (youtube.com)

The source code: https://github.com/HighwayFrogs/frogger2-vss

I enjoyed skimming through this: https://github.com/HighwayFrogs/frogger2-vss/blob/main/teamS...

Another entertaining piece by the Lego Island guy!

My takeaway is that you should choose a passion project as your hobby and put in the time to learn and do whatever is necessary to achieve your goal on your own or together with similarly motivated people rather than relying on anyone external you have to pay - things go downhill fairly often and quickly it seems. Is any business a scam to some degree nowadays?

I'm not surprised by the data recovery company story, it feels like I only hear bad things about that industry. I remember something similar happened with LinusTechTips.

I once wrote a DAM that wrote to LTO tapes just using tar. The tape was operated with forward/rewind commands from mt. Nobody needed access to the tapes until after I was no longer at the company. Apparently, they spent weeks trying to install various backup software to read the tapes, but none could. They eventually contacted me, but due to how much software they had tried to use the original computer it was attached to was no longer the OS. At that point, they asked 3rd party companies for help and eventually found someone with a drive attached to a Linux system. I was then able to walk them through how to read and extract data.

Tape storage can be an absolute nightmare. Most will do the writes, some will say they verify with a read, but few actually test with a full restore. Just because the software says it can read the tape to show you the listings does not mean it can read the files themselves. This was alluded to in TFA(TFV??) but been there done that on trying to read from a bum tape/bad write. It gets worse if you write in one tape drive and read from another also mentioned in TFV. Now I feel old just thinking about it all

Absolutely heroic effort. And that data recovery company should go out of business.

  • It is named and shamed in the comments of that video somewhere.

    Data recovery companies ought to have the integrity to just say no to a job, if they cannot do it risk free. Trying and failing with the risk of damaging the original data could be very costly to the customer, even if they don't charge money - the customer's lost data could be priceless.

A lot of work, but with success as reward! Makes you wonder how easy or difficult it will be in 30 years to 'recover' data from today.

  • > Makes you wonder how easy or difficult it will be in 30 years to 'recover' data from today.

    The challenges will be different. Flash loses its charge in 30 years, most disks are encrypted, and on-site physical backups are mostly a thing of the past. The source might survive in a cloud repo, but it'll either be tied up for legal reasons or deleted when the customer stops paying the bill. But storage is cheap and getting cheaper!

    • Data not continuously copied is lost. Ironically the most future proof media is becoming increasingly rare. Those gold layer dvds may last well into the future but the readers will not be available.

      1 reply →

    • Flash seems to lose its charge a lot faster than that, -- I found ordinary SSDs left in a closet for two years to be full of errors while matched sibling drives left in running systems were fine.

    • Easy. The “deleted” even overwritten data can leave ghosts even multiple layers deep (think of a clay tablet or painting with multiple inscriptions)

      Encryption for 30 years ago? Trivially breakable with quantum

      16 replies →

  • Hard, but it depends on backup / duplication strategies; this is why e.g. the internet archive is so important, and I hope there are multiple parties doing the same thing for redundancy.

  • Hard. I am slowly writing a book set in the future where we are a “digital dark age” where little to nothing is known about our time tentatively called Professor Bitrot.

This seemed to be a point of confusion in the original story and the video wasn't super clear but:

Pretty much all tape backup software writes headers as it is streaming the file to tape. Just more bytes in the buffer.

For normal restores it consults its local database because that is way faster. If you don't have the local database you do a "Catalog Tape" operation that scans the file headers on the tape to reconstruct the database. For whatever reason ARCServe couldn't complete the catalog with that specific kind of tape. Whether that was the specific version he found or was a general problem with support for those tape drives I don't know.

AFAICT the way most 'recovery' places work is that they'll recover data if there are no issues and any ordinarily skilled IT tech could also recover it. And then otherwise they'll claim it's unrecoverable. Sometimes, it seems, they'll even just claim its unrecoverable because they didn't happen to have or find a compatible drive when that's all that was needed.

I've recovered data from media a number of times a recovery company said it was unrecoverable with no particular difficulty.