Fix handling of local file header for 3TZ #173
Conversation
|
While creating specs for this, I noticed that there is another hard-wired (wrong) constant of 320 bytes that was carried over from the original implementation, meaning that the functions cannot read 3TZ files that are smaller than 320 bytes (like the one that I just created for the specs 😬 ). I'll add a fix for this as well... |
|
... and this fix was pretty trivial: Just don't try to read more than the file size, as in I also added some spec files for the 3TZ reading functionality that explicitly covers these corner cases. (There are other specs that causally deal with 3TZ, but that do not cover some of these low-level details) |
|
I think that this could be ready for review, but I'll use this state more extensively for tests in the |
|
I tested this more extensively, in the context of CesiumGS/3d-tiles-validator#332 , with real-world tilesets that contain (many, huge) 3TZ files, and everything seemed to work properly. So this should be good to go. |
There have been reports of 3TZ files that could not be read due to improper handling of the "extras" field in local file headers. The 3TZ reading functions simply assumed that the "extras" are at most 48 bytes (and I don't know where this value came from). But certain files that had been accessed with certain tools could contain extras that contained more than 48 bytes (in a "Windows NT Security Descriptor Extra Field", see specs).
The change here removes the assumption of these 48 bytes. The archive functions now explicitly look at the actual size of the extras field in the header, and then use this to compute the offset at which the actual file data can be read.
I'm opening this as a "draft" for now. I'd like to add some tests/specs. But in terms of 3TZ, there currently is zero test coverage, and I don't know how the problematic files had been created, so it's not entirely clear how the test coverage could sensibly be increased here...