fsck.fat does not repair directory entries starting with 0x00 -

[xentrax]

According to https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system#Directory_entry 0x00 has the following meaning:
"Entry is available and no subsequent entry is in use. Also serves as an end marker when DOS scans a directory table."

If, due to corruption, such directory entry appears in the directory file, Windows cannot see files listed after such directory entry in all the subsequent clusters of the directory file.

Windows chkdsk repairs this situation. fsck.fat does not.

Currently it just ignores such directory entry:
https://github.com/dosfstools/dosfstools/blob/v4.2/src/check.c#L924

vfat also behaves this way and thus Linux does not stop scanning directory upon encountering such entry, the problem can only be seen when the media is accessed from the Windows machine.

[pali]

Do you know what is windows chkdsk doing with directory which has following entries in this order? valid, null, valid, valid.

Does it restore null entry as non-null? Or it moves valid entries which are after null to position where is null entry? Or does it remove all valid entries which are after null?

I see there lot of options what can be done in this situation and I do not know what is there correct way to repair such directory.

There can be fully valid directory which has null entry (as end marker) after which is nothing (either null entries or entries marked with 0xE5 as deleted) and corruption can change these entries after null entry to non-null.

Or there can be fully valid directory without any null entry and corruption happens which change some entry to null.

Or there can be fully valid directory without any null entry and corruption can change valid entry to deleted entry (with 0xE5).

[xentrax]

Yes, it is a difficult question.

In my experiments Windows chkdsk did the following:
It simply marked with 0x00 first byte all subsequent directory entries in this directory.
It then tried to repair contents of the files as lost cluster chains.

As I can see vfat seems to behave the same way as fsck.fat in regards that 'ls' lists all other files in the directory even past the 0x00 entry. This means it should be safe to convert 0x00 to 0xE5. After that Windows will see the directory in the same way as currently vfat does.