search

relan / exfat

Free exFAT file system implementation
GNU General Public License v2.0
795 stars 182 forks source link

ERROR:unexpected entry type 0xffffffff after 0x85 at 1/1. #110

Open feanshion opened 5 years ago

feanshion commented 5 years ago

Hi,relan,

My hard disk file system is exFAT，plug out it from PC when do write operation，and then this issue is occurred，fsck.exfat can find this issue but can not fix this issue, is there some advices of this issue?

BR.

feanshion commented 5 years ago

can u reply this issue?please

relan commented 5 years ago

plug out it from PC when do write operation，and then this issue is occurred，fsck.exfat can find this issue but can not fix this issue, is there some advices of this issue?

Recreate the file system and restore your data from a backup.

feanshion commented 5 years ago

Hi,relan, I can see V1.3.0 can repair some errors, do u have a method to repair this issue? recreate is too complex to end-user and maybe loss data. In windows OS, I can use chkdsk to repair this issue, but we hope have a repair method on Linux OS. BR.

relan commented 5 years ago

I can see V1.3.0 can repair some errors, do u have a method to repair this issue?

Not this one.

we hope have a repair method on Linux OS.

Don't expect this to happen. I have very little spare time.

xeruf commented 3 years ago

I am having the same issue with an unfortunately not fully backed up SD-Card:

ERROR: unexpected entry type 0x48 after 0x85 at 1/150.

I have already successfully used hexedit to repair the upcase table, is there a manual solution possible here? What does 1/150 refer to?

relan commented 3 years ago

is there a manual solution possible here?

You can try to zero out the offending entries. Look for 0x85 followed by 0x48.

What does 1/150 refer to?

The 2nd byte (+0x01 offset from the beginning) of the entry 0x85 contains the number of subsequent entries. They compose a file entry (some metadata + a file name). 150 subsequent entries is quite a lot, this value may be incorrect.

xeruf commented 3 years ago

Well the SD card has 400GB, so I guess it is not unreasonable to have many entries. My issue is that I only found this byte combination within what looked like data, how would I locate it?

relan commented 3 years ago

My issue is that I only found this byte combination within what looked like data, how would I locate it?

Get the source code, remove this line, compile fsck and run it against the broken image. It'll show what it's checking.

xeruf commented 3 years ago

I tried that, but the output did not change. How can I find out what went wrong? I published my attempt to the AUR in case that helps: https://aur.archlinux.org/packages/exfat-utils-debug-git/