* Look for the Wise overlay header before opening the file again
ExtractWiseOverlay (and ExtractWise for NE) opened a second stream on
the executable for multi-part Wise installers before checking for a
Wise overlay header at all. For any other executable that stream was
never closed, so the file stayed open until the stream was finalized.
On Windows such a file cannot be deleted, so an extraction folder that
contains it is left behind in TEMP.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Close the Wise script and the multipart file after extraction
ExtractWiseOverlay (and ExtractWise for NE) never closed WiseScript.bin,
which it opens from the output directory, nor the stream with the
installer and its parts, so these files stayed open until their streams
were finalized.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Keep the original block that opens the multipart file
Close the multipart stream with a separate using declaration after the
block instead of rewriting it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
ExtractWiseOverlay (and ExtractWise for NE) opened a second stream on
the executable for multi-part Wise installers before checking for a
Wise overlay header at all. For any other executable that stream was
never closed, so the file stayed open until the stream was finalized.
On Windows such a file cannot be deleted, so an extraction folder that
contains it is left behind in TEMP.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* Locate the PKZIP file data instead of reading it into the model
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Keep only the offset of the PKZIP file data
The length is the compressed size from the local file header or the ZIP64
extended field, which the printer already shows.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Keep the file data property as a comment for documentation
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
The DAT writers and the filter formatted Refresh and Freq with the
current culture, so a German or French system wrote "123,450000".
SabreTools.IO parses these values with the invariant culture.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
ParseDirectory parsed the big-endian extent when the extent location
was valid (both values equal) instead of when it was ambiguous, so
every directory was parsed again, once per directory level.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
