Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Error when read xls file

See original GitHub issue

when use release 3.0.0-develop00086 and 3.0.0, read xls file throw system.invalidoperationexception “The excel file may be corrupt or truncated. We’ve read past the end of the file.”, but ExcelDataReader 3.0.0-develop00019 is ok. stacktrace : 在 ExcelDataReader.Core.BinaryFormat.XlsDocument.ReadSectorTable(BinaryReader reader, List`1 chain) 在 ExcelDataReader.Core.BinaryFormat.XlsDocument…ctor(Stream stream) 在 ExcelDataReader.Core.BinaryFormat.XlsWorkbook.ReadCompoundDocument(Stream stream) 在 ExcelDataReader.Core.BinaryFormat.XlsWorkbook…ctor(Stream stream, Encoding fallbackEncoding) 在 ExcelDataReader.ExcelBinaryReader…ctor(Stream stream, ExcelReaderConfiguration configuration) 在 ExcelDataReader.ExcelReaderFactory.CreateBinaryReader(Stream fileStream, ExcelReaderConfiguration configuration)

Issue Analytics

State:
Created 6 years ago
Comments:13

Top GitHub Comments

1reaction

andersnmcommented, Jul 17, 2017

It’s fixed in develop, but haven’t added test data yet.

The bug looks to trigger with any XLS above ~15 megabytes. The big test file in the repo “GitIssue_184_FATSectors.xls” looks to be just below the threshold to trigger the bug. 😦

Each DIFAT entry describes 128 data sectors/entries at 512 bytes. There are 109 DIFAT entries in the header, plus optional DIFAT sectors elsewhere in the file. Each DIFAT sector contains 127 entries plus a link to the next DIFAT sector. There has to be at least one full DIFAT sector for the bug to happen. Thus, ((109 + 127) DIFAT entries *128 data sectors) * 512 bytes ~= 15 megabytes.

0reactions

merlinyygcommented, Jul 21, 2017

@andersnm build 3.1.0 101 is working well for me. Thanks!