Hi Peter, Thank you for letting me know. I could reproduce the bug with the provided image. I exchanged the "break;" with a "return 0" in upstream version 0.9.11.
Thanks for helping me making fatsort better! Boris On 09/26/2009 02:27 PM, Peter De Wachter wrote: > I figured out the cause for the segfault in writeClusterChain. > > Boris, I previously reported this issue to the Debian bug tracking > system. If that report didn't reach you, you can read it at > http://bugs.debian.org/543986 . > > You can download a disk image at: > http://igwe.vub.ac.be/~pdewacht/fatsort-bug-image2.bz2 > (54MB compressed, 8GB uncompressed). > > On this file system, the root directory looks like this: > > cluster 2: > entry 1: long name: ##MUSIC# > entry 2: short name: ##MUSIC# > ... > entry 15: long name: SYS_CONF.SYS > entry 16: short name: SYS_CONF.SYS > entry 17: empty > cluster 549234: > entry 1: deleted file: ?SCK0000.050 > entry 2: empty > > When the parseClusterChain function sees the empty entry in the first > cluster, it stops processing that cluster but continues with the next > one in the chain. It then encounters the deleted file, for which it > generates a sDirEntryList record with an incorrect entries field. > When fatsort later tries to write out that record, it segfaults. > > The information I collected on FAT indicates that after an empty > entry, no in-use entry can follow (i.e. only empty entries and deleted > files can follow). So it should be okay for fatsort to stop following > the chain after encountering the first empty entry. The attached patch > implements this, and fixes my segfault. > > Peter De Wachter -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
