For our application we're using Excel files as our file format. We're simply changing the file extension - but our "native" format is really xlsx. Of course we're using Flexcel to create the Excel file.
Earlier today someone sent me a file which was corrupted. It seems to be truly corrupted. Excel is unable to open / repair it. I've attached the file in question (https://dl.dropboxusercontent.com/u/112833/Central%20Region%20Rev1%20MH%20-%20Copy.xlsx). Maybe you can take a look and see if it could have been caused by a bug in Flexcel. I'm using Flexcel version 6.7.0.0
I'm not sure if Flexcel was the cause of the corruption. It could have been something unusual on the client's machine - although when I spoke with her she said it had saved as normal.
To me this seems just like a truncated file. Of course, one can never be 100% sure, but some hints:
1)The file is exactly $A0000 bytes. Which is exactly 640kb, or 320 sectors in an NTFS system with 2K per sector.
2)Xlsx files are just zip files. You can rename an xlsx to .zip, and open the zip to see inside. If you check this zip with 7Zip, it will tell you the zip itself is corrupt.
3)If you open a zip file with an Hex editor, you should see the signature "PK#06#05" near the end of the file. All zip files end up with a central directory descriptor an optionally a comment (but FlexCel will never write any comment, so if the file was generated by FlexCel it should end with the central directory descriptor). A central directory descriptor starts with the signature PK#06#05:
The file starts well, with a PK signature, but at the end (exactly at offset $A0000) it seems like it is just lacking more sectors which should complete the data, and of course it lacks a central directory descriptor.
4)If you open the file with 7Zip, Sheet1 is correctly saved (the data is there) but sheet2 is not finished.
It all looks like there is a missing part of this file. I am not sure on how this could happen, but FlexCel will always write the central directory offset at the end. Maybe a disk full so it couldn't write after the 320th sector? (but that should raise an exception)
