A Real Archive Roundtrip and Better File Behavior

One of the more useful October results was getting an ordinary archive workflow to finish. The original 7zr 26.04 command-line tool created an archive from four files, tested it, and extracted it. The extracted files were compared with the originals, including their complete bytes and CRCs.

That is a more useful result than a help screen, although the help screen was an earlier step in understanding the program's behavior. The work had to correct file-type reporting and other file APIs that applications use to decide how to handle their input and output. A wrong answer about a handle can change what a program does even when the next read or write function looks correct in isolation.

Directory enumeration, clocks and alignment, allocation, and file metadata also received focused fixes and comparisons. The recorded candidate had 35 targeted cases across those areas, followed by repeated checks on the later archive candidate. These cases help explain why the application advanced; they aren't a count of supported programs.

The archive run used the original single-threaded command. I'm keeping that qualification because the default multithreaded path still needs its own acceptance. I'm also keeping this result separate from the older 7-Zip 26.02 installer test. They prove different workflows on different development builds.

The native 64-bit ReadFile path was exercised too, including short reads, end-of-file behavior, zero-length requests, invalid handles, file position, and protected or released memory. Those checks tested actual buffer and output effects instead of relying only on an exit status.

For a user, opening and extracting an archive should be unremarkable. For the port, it was a helpful application milestone: real code scanned real files, wrote an archive, and got the originals back. The newer builds were still external development candidates awaiting the broader regression and application work needed before adoption.