I'm on Linux.

[nicolai@babka.social]

@mcc testdisk and photorec. And make a copy with GNU ddrescue before

[joriki@infosec.exchange]

@mcc

maybe possibly: bootrepair

[lynndotpy@mastodon.social]

@mcc Other advice to make a copy and then use testdisk / photorec are good. But if you haven't checked with a known good card already, maybe the reader / adapter could be an issue too?

[mhoye@cosocial.ca]

@mcc I see that other people have already mentioned them, but the right answer is testdisk/photorec and I've seen them save the day more than a few times.

https://www.cgsecurity.org/wiki/PhotoRec

[realcainmosni@mastodon.me.uk]

@mcc Best you can do is image the device - if it is readable at all - and work with that. Do NOT try to work with the device directly if you can avoid it. Corruption lies in that direction. From now on treat it as read only (which also means not attempting to mount it, again).

[realcainmosni@mastodon.me.uk]

@mcc There are forensic tools which will help make sense of the image if you can get one at all. Binwalk on the image, for starters. A bit overblown for your use case, but there's also Sleuthkit and Autopsy (proper forensic tools, which are great for data recovery, if you have the time and dedication).

[simon@gotosocial.grnwds.uk]

@mcc
TestDisk might work but haven't tried it with exfat. It's very good for Linux filesystems. https://www.cgsecurity.org/wiki/TestDisk_Download

[davep@infosec.exchange]

@mcc This sort of thing but without the live Linux USB?

https://www.thelinuxvault.net/linux-backup-recovery/step-by-step-linux-data-recovery-tutorial/

[davep@infosec.exchange]

@mcc I'd go down straight to the "make an image" bit first.

[spacelifeform@infosec.exchange]

@mcc

Probably tosst. What does fdisk -l /dev/sda report?

[evan@cosocial.ca]

@mcc I've had good results with ddrescue and external drives.

https://www.gnu.org/software/ddrescue/

[jamesd@mastodon.social]

@evan @mcc Also had good results with ddrescue on very old 720MB floppies that had problems.

[thatdnaguy@genomic.social]

@mcc second photorec. I've recovered files from borked SD cards using it on Ubuntu

[mcc@mastodon.social]

@SpaceLifeForm without trying, I'd guess it reports that my internal drive (not exfat) is not exfat?

[spacelifeform@infosec.exchange]

@mcc

Yes. What does fdisk -l /dev/sdb report?

Compare.

[spacelifeform@infosec.exchange]

@mcc

Do you have a second computer to try the drive in?

Don't give up too soon.

[mcc@mastodon.social]

@SpaceLifeForm It's in the screenshot above

[mcc@mastodon.social]

@SpaceLifeForm im watching anime

[muddle@infosec.exchange]

@mcc @SpaceLifeForm It doesn't. Your screenshot shows running fsck not fdisk.

The latter will read the partition table and print it out for you, including telling you what kind of partitions it has and whether there are overlapping ones.

One thing to try (besides just copying the disk, which you should do) is to see if the file utility has any idea about what's stored in that partition. Something like

sudo dd if=/dev/sdb1 bs=512 count=4 | file -

I've seen plenty of USB disks that appear not to have a proper partition table or boot sector, but they still work fine as a boot disk. I'm not sure if you remember writing the image (I always promptly forget which disk has what on it) but that might be the case here?

Anyway, copy the disk, save the image and you can work from that later. Just make sure that the tool you use detects and records any read errors.

(under Linux, you can use loopback mounts to mount from an image at a given offset instead of using a physical disk)

[mcc@mastodon.social]

@muddle @SpaceLifeForm Oh. Thanks. I misread.

I'll try that one tomorrow, along with the other suggestions. Thanks.