Skip to content

Running unzip process outputs process output in unzipped files #1

@demarey

Description

@demarey

Can be reproduced by using unzip exe provided by git for Windows:

OSWSWinProcess new.
process 
	shellCommand;
	arguments: #('"C:\Program Files\Git\usr\bin\unzip"' '-o' '-d' '"C:\Users\me\Documents\Pharo\vms\70-x64"' '"C:\Users\me\Documents\Pharo\vms\70-x64.zip"');
	runAndWait;
	isSuccess

After unzipping, files are corrupted. Every (binary) file in the archive starts with some string that seems to be from the unzip progress report:

$ strings 70-x64/FT2Plugin.dll | head
  inflating: C:\Users\me\Documents\Pharo\vms\70-x64/FT2Plugin.dll  MZ
!This program cannot be run in DOS mode.
.text
P`.data
.rdata
`@.pdata
0@.xdata
0@.bss
.edata
0@.idata

It seems that the stdout output from unzip is written to the files!?

The problem could be fixed with:

OSWSWinProcess new.
process 
	shellCommand;
	arguments: #('"C:\Program Files\Git\usr\bin\unzip"' '-o' '-d' '"C:\Users\me\Documents\Pharo\vms\70-x64"' '"C:\Users\me\Documents\Pharo\vms\70-x64.zip"' '> nul');
	runAndWait;
	isSuccess

The setup of the stdout handle is given in a struct called StartupInfoW. But the code looks sane, the startupinfo sent in this FFI call is all zeros. Thus the fallback would be the console window's buffer:

hStdOutput

If dwFlags specifies STARTF_USESTDHANDLES, this member is the standard output handle for the process. Otherwise, this member is ignored and the default for standard output is the console window's buffer.

So next questions I have are: which process writes the console window's buffer? And why is written to disk along with the unzipped binaries?

Problem reported by @zormit on Pharo Launcher issue tracker. See pharo-project/pharo-launcher#349

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions