You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
[email protected][email protected]
.edata
[email protected]
It seems that the stdout output from unzip is written to the files!?
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?
For information (if ever this bug came up again despite last fix to pharo-project/pharo-launcher#349) : same issue here on win7-64 with VMs downloaded and extracted through Pharo Launcher v1.9.2
Environment-specifics : CygWin-installed unzip 6.00 is on the path here.
Same symptoms as previously described :
C:\>strings C:\Users\me\Documents\Pharo\vms\80-x64\FT2Plugin.dll | head
inflating: C:\Users\me\Documents\Pharo\vms\80-x64/FT2Plugin.dll MZ
!This program cannot be run in DOS mode.
[z[\
.text
P`.data
.rdata
`@.pdata
[email protected][email protected]
.edata
Can be reproduced by using unzip exe provided by git for Windows:
After unzipping, files are corrupted. Every (binary) file in the archive starts with some string that seems to be from the unzip progress report:
It seems that the stdout output from unzip is written to the files!?
The problem could be fixed with:
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:
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
The text was updated successfully, but these errors were encountered: