Gwolf

FAT hex dump

Latest comment: 10 years ago4 comments2 people in discussion

Hi Gunnar, I saw that you recently uploaded two hex dumps to illustrate the FAT article. The first one contained a number of bugs and peculiarities, this is why I replaced it by a table (with an artificially created, but somewhat more illustrative example). However, one of the peculiarity (...F8h end-of-chain marker for the root directory) raised my curiosity, since Linux is said to no longer use ...F8h as end-of-chain-marker (why this should be technically okay, it is non-standard and caused compatibility problems with other (buggy) implementations) for some while now. Which version of Linux did you use to produce this hex dump? Does this only occur for the root dir, or also for other directories? Does it happen when formating the volume or later at runtime when you change files? I am interested in this, since it might mean that the FAT filesystem driver in Linux could be further improved. --Matthiaspaul (talk) 10:11, 17 April 2014 (UTC)Reply

→ Yes, the ...F8 also got my eye and made me do the tests over. I did it again, now including a subdirectory, and got the same results. I am almost sure I did the versions I uploaded on my work machine, which has a 3.13 Linux kernel (probably was 3.12 back then), and did the tests on my laptop, which runs Linux 3.2. The resulting work directory is:

   00009800  41 74 00 65 00 73 00 74  00 00 00 0f 00 32 ff ff  |At.e.s.t.....2..|
   00009810  ff ff ff ff ff ff ff ff  ff ff 00 00 ff ff ff ff  |................|
   00009820  54 45 53 54 20 20 20 20  20 20 20 10 00 00 92 41  |TEST       ....A|
   00009830  91 44 91 44 00 00 92 41  91 44 03 00 00 00 00 00  |.D.D...A.D......|
   00009840  41 74 00 65 00 73 00 74  00 66 00 0f 00 e8 69 00  |At.e.s.t.f....i.|
   00009850  6c 00 65 00 2e 00 64 00  61 00 00 00 74 00 00 00  |l.e...d.a...t...|
   00009860  54 45 53 54 46 49 4c 45  44 41 54 20 00 00 96 41  |TESTFILEDAT ...A|
   00009870  91 44 91 44 00 00 96 41  91 44 0e 00 00 1c 00 00  |.D.D...A.D......|
   00009880  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

The test subdirectory:

   00009a00  2e 20 20 20 20 20 20 20  20 20 20 10 00 00 86 41  |.          ....A|
   00009a10  91 44 91 44 00 00 86 41  91 44 03 00 00 00 00 00  |.D.D...A.D......|
   00009a20  2e 2e 20 20 20 20 20 20  20 20 20 10 00 00 86 41  |..         ....A|
   00009a30  91 44 91 44 00 00 86 41  91 44 00 00 00 00 00 00  |.D.D...A.D......|
   00009a40  41 74 00 65 00 73 00 74  00 66 00 0f 00 e8 69 00  |At.e.s.t.f....i.|
   00009a50  6c 00 65 00 2e 00 64 00  61 00 00 00 74 00 00 00  |l.e...d.a...t...|
   00009a60  54 45 53 54 46 49 4c 45  44 41 54 20 00 00 92 41  |TESTFILEDAT ...A|
   00009a70  91 44 91 44 00 00 92 41  91 44 04 00 00 14 00 00  |.D.D...A.D......|
   00009a80  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

And the first FAT table:

   00004000  f0 ff ff 0f ff ff ff 0f  f8 ff ff 0f ff ff ff 0f  |................|
   00004010  05 00 00 00 06 00 00 00  07 00 00 00 08 00 00 00  |................|
   00004020  09 00 00 00 0a 00 00 00  0b 00 00 00 0c 00 00 00  |................|
   00004030  0d 00 00 00 ff ff ff 0f  0f 00 00 00 10 00 00 00  |................|
   00004040  11 00 00 00 12 00 00 00  13 00 00 00 14 00 00 00  |................|
   00004050  15 00 00 00 16 00 00 00  17 00 00 00 18 00 00 00  |................|
   00004060  19 00 00 00 1a 00 00 00  1b 00 00 00 ff ff ff 0f  |................|
   00004070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

Note that I use Linux almost exclusively since 1996, and never had any problems to interchange data on FAT partitions.

Gwolf (talk) 13:37, 17 April 2014 (UTC)Reply

Great, thanks for your fast and very helpful reply. Old versions of Linux used F8h as end-of-chain marker, but this was changed to FFh with 2.5.40 for compatibility reasons. Apparently they overlooked to change the marker in one location.

Based on your examples, we can be almost sure, that the issue exists only on FAT32 volumes and only for the root directory, and that it happens during format. Since the root dir starts in cluster 2 most of the time, this might be down to a left-over in some template.

It is not actually a bug, since F8h-FFh are all valid end-of-chain markers, but according to AEB some buggy MP3 players in the wild happen to only test for FFh. Personally, I have seen some buggy FAT32 boot sectors requiring FFh instead of accepting F8h-FFh as well.

So, while not a bug, it should be changed in Linux in order to further improve compatibility. --Matthiaspaul (talk) 23:23, 17 April 2014 (UTC)Reply

Small update: I found the cause of the problem in the code and will be working with Daniel to fix it. Thanks again. --Matthiaspaul (talk) 00:41, 18 April 2014 (UTC)Reply

Add topic