After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 763376 - gcab fails to extract empty files in folders without data
gcab fails to extract empty files in folders without data
Status: RESOLVED FIXED
Product: msitools
Classification: Other
Component: gcab
0.95
Other Linux
: Normal normal
: 1.0
Assigned To: msitools maintainer(s)
msitools maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2016-03-09 14:59 UTC by Mattias Engdegård
Modified: 2016-03-09 17:24 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
emptyfiles.cab (88 bytes, application/vnd.ms-cab-compressed)
2016-03-09 14:59 UTC, Mattias Engdegård 		Details

Description Mattias Engdegård 2016-03-09 14:59:08 UTC 
Created attachment 323517 [details]
emptyfiles.cab

Gcab does not extract files of size zero in folders with no CFDATA chunks, but aborts with a generic "unexpected end of stream" error.

Such cab files are readily produced by available tools; attached is one produced by makecab.exe, simply by asking it to create a cab from two empty files, file1 and file2. As you can see, the files both belong to a folder without CFDATA.

The gcab utility will crash during the extraction of one of them. Other tools extract both files successfully.
Comment 1 Marc-Andre Lureau 2016-03-09 15:23:02 UTC 
thanks, are you working on a fix?
Comment 2 Mattias Engdegård 2016-03-09 15:31:37 UTC 
I'll give it a go if I can spare some time. It's probably trivial.
Comment 3 Marc-Andre Lureau 2016-03-09 16:28:13 UTC 
fixed in git

(In reply to Mattias Engdegård from comment #0)
> The gcab utility will crash during the extraction of one of them. Other
> tools extract both files successfully.

"gcab: error during extraction: Unexpected early end-of-stream", not really a crash.
Comment 4 Mattias Engdegård 2016-03-09 17:24:54 UTC 
(In reply to Marc-Andre Lureau from comment #3)
> fixed in git

Thanks! Your change (do-while changed into while) was identical to the one that I was preparing, so it was rather obvious.