OCTADE

@octade@soc.octade.net

(Owner soc.octade.net) (5&2)()()

Director of the International Department of Civil Disobedience.

For thoughtful response to thoughtful inquiry contact my email. Don't send me private direct messages on the Fediverse. If you have a general question ask it in a public timeline. I block users who send me annoying private messages about things that should be asked in a public timeline.

I sometimes post links to items I find curious, interesting, or of research and study value. This does not necessarily mean that I agree with the linked matter. Don't assume.

NAME : Raze
ACADEMIA.EDU
ABOUT
LINKS

SLOGAN : Speak not with words. Speak with work product.

PRONOMS : | | | | | |





LINKS

Cryptography project site
Publications
ORCID
[Netnews] Find me on in alt.flashback, alt.crossover, alt.rhubarb.
Git Repositories
Keyoxide1
Keyoxide2
BlueSky
HackerNews
Internet Archive

1 ★ 0 ↺

[?]OCTADE ยป 🌐
@octade@soc.octade.net

@mcc@mastodon.social

The suggestion at the end of this might be a viable option.

Use application, 'testdisk' to analyze without writing any changes. If it can detect the lost exfat tables then it can be recovered. I have done this with multiple failed media and drives. Be sure to read the documentation carefully before running it.

Exfat writes a backup boot region. Testdisk should be able to check for this.

If that doesn't work there is ddrescue and photorec for finding and recovering individual files.

You might also use 'dd' to raw copy the damaged volume to an image file and write that image file to other external media then try running 'testdisk' and other tools on the copy. You can keep the image file as a backup as you try to recover the data from a copy first, to avoid the risk of further damage to the card.

    History

    about this site - powered by snac/2.93-dev