1

I wonder what the alternatives could be.

If I did not try the scan and repair prompted by the Windows, everything probably are still normal or can be salvaged more easily.

(Fat32 single 256GB partition, sd card formatted through android phone allows a single 256gb partition with fat32 File System)

(android do not natively support NTFS, my phone does not recognize NTFS, didn't want third party file manager, need to transfer files between windows and android, my phone can only format sd card into a single partition fat32 filesystem with no any other options, so fat32 it is)

The Phone experienced sudden reboot during the file transfer to SD card(phone's USB C port to SD card reader). Before chkdsk scan and repair, I used command line chkdsk read-only and it shows no error, I browsed some of the card's folders and played a partly transferred media file, all were normal, that partly transferred media can playback what it partly got transferred which is reasonable.

The windows was prompting me to scan and fix the sd card right after I insert the card reader into PC's usb port, I ignored it at first and tried what I described above, everything was okay. But after a few times of the safe remove and reinsert the sd card reader, the prompt still remain, so I gave the scan and repair a try, then the folder contain that half transferred file and some of other folders and files in the sd cards root folder all disappeared and turned into a Found.000 folder filled with .CHK files.

Another thing is, after the phone suddenly reboot by itself, it was not recognizing sd card reader, I tried eject - pull out - plug it back in multiple times, tried the windows's suggestion to scan and fix, still nothing, then I reboot the phone manually and plug in the reader, it was recognized and files in it was playable.

So the scan and fix/repair prompted by windows was definitely the last thing one should do.

Thank you all for your answers.

Improve this question
8
  • Chkdsk doesn't give a damn about your files & will gladly sacrifice each & every one of them in order to do its job - fix the file system. There were inconsistencies in the file system - now there aren't.
    – Tetsujin
    Commented Jun 7, 2022 at 16:13
  • BTW, to at least partially mitigate against this type of thing happening again, you need to be using a Journaled file system, HFS, NTFS etc. FAT & all derivatives cannot journal, so if there's an issue during write, there's no record of what the write operation was doing at that moment & file loss is a common result.
    – Tetsujin
    Commented Jun 7, 2022 at 16:31
  • Most android phone can't natively support removable external storage with journaled file system, and I tried NTFS my phone did not recognize it, windows natively can't format fat32 with 256g single partition neither, my phone got no other options other than format, then I got a single 256G fat32 partition. exfat formatted through PC was not recognized neither.
    – Sij
    Commented Jun 7, 2022 at 16:50
  • I don't know man, files were normal before I followed windows's instruction to scan and fix/repair. There are thousands of files+ folders, only 1 of them were writing at that moment, it's not fair that all of them are turned into .CHK files
    – Sij
    Commented Jun 7, 2022 at 16:52
  • Or stock android system do not natively support ntfs file system, I'm using Android one phones, to avoid unnecessary things as much as possible.
    – Sij
    Commented Jun 7, 2022 at 17:09

3 Answers 3

Reset to default
2

The sudden reboot of the phone caused inconsistent file-system tables on the SD card.

Doing chkdsk then "repaired" the inconsistencies, but destroyed some files. (The operation was successful, but the patient died.)

I would suggest to reformat the SD card and re-transfer the files from the phone. There is no way to repair the destroyed files on the SD card or return it to its state as before the chkdsk.

Improve this answer
3
  • Only 1 file were writing at that moment of the reboot, thousands were turned into .chk files with it. Oh man.
    – Sij
    Commented Jun 7, 2022 at 16:58
  • 1
    @retardate At least two data locations were being actively written to at the moment of reboot, the file itself and the file system metadata. The file may or may not have been corrupted. The metadata definitely was.
    – doneal24
    Commented Jun 7, 2022 at 17:27
  • @doneal24 Oh man. At least files and folder structures were recognizable before scan and repair, now it's thousands of FILE000*.CHK in a FOUND.000 folder, I should try copy files out first next time.
    – Sij
    Commented Jun 7, 2022 at 17:37
1

Did you have it plugged in any time before that? If you have file backup enabled follow these steps:

  1. Right-click the drive
  2. Select "Properties"
  3. Go to "Previous versions"
  4. Select the time/date you last remember the files being uncorrupted This should restore the files @retardate Sometimes Windows will misread files and give it an unknown file name/extension. This happened to me, I changed an .efw file to an .exe and worked.
Improve this answer
1

Chkdsk cares about consistency of the file system and tries to fix that as others in the comments already mentioned. In the process it mostly fixes 'references', chances are actual file content is recoverable as long as no more repair attempts are made. So chkdsk removes references for files from file system and saves data from now unreferenced clusters to these .chk files.

If you're looking to recover the data, First step should be to image the card, and by image I mean a sector-by-sector disk image. Most decent file recovery tool demos allow you to do so, example https://youtu.be/870lfHqS0RU. Ideally you copy the disk image so you have an extra safety net.

Now we have several options.

  1. Mount the disk image using the free OFSMount (free). This will assign the image a drive letter and there's a chance you can access it using Explorer. Copy the chk files to another drive. You can then try one of the multiple 'chk file recovery' tools (some examples). These are very simple, they check if the 'header' of a .chk file matches a known file type. So for example if first few bytes of the chk file are FF D8 we may be dealing with a JPEG file and the tool will rename the file accordingly.

  2. Run a file carver directly on image. Such a tool uses a kind of similar technique, it examines sectors and sees if they contain a known file signature. PhotoRec relies on this method, and it's free and open source.

Both methods are bound to produce a fair number of corrupt files or false positives so do not expect 100% results. Also you will have to go through the files (open them) to see which ones worked.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .