bug with csectFat=1 #1
Description
Originally reported by: Philippe Lagadec (Bitbucket: decalage, GitHub: decalage2)
Bug reported by Martijn:
I found a rather odd file where the FAT sectors after the header look like:
len(sect)=436, so 109 integers
index 0 1 2 3 4 5 6 7
0: BA BB FFFF FFFFFFFF FFFFFFFF FFFFFFFF
FFFFFFFF FFFFFFFF
OleFileIO_PL breaks because it can't read sector 0xFFFF. However, this file is (in a sense) valid because csectFat in the header says 2 so it shouldn't even try reading sector number 3.
I can't find in the specification that the remaining values must be 0xFFFFFFFF, though I suppose you could make a warning for it.
Ok, here is the debug output. I can't send the original file
unfortunately, but with a bit of hex editing I got the attached file.
The basic idea is that cSectFat = 1, so it doesn't matter that the
second entry is invalid. I don't know how the original file got like
this, it's not reproducible. Patch is attached. In theory you could
produce a warning in these cases instead, but as long as it's not
fatal you can properly read the rest of the file.
[see debug.txt]