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 747091 - Wrong size got when try to extract a compressed 'tar.gz' package(including a sparse file)
Wrong size got when try to extract a compressed 'tar.gz' package(including a ...
Status: RESOLVED FIXED
Product: file-roller
Classification: Applications
Component: general
3.10.x
Other Linux
: Normal critical
: ---
Assigned To: file-roller-maint
file-roller-maint
Depends on:
Blocks:
 
 
Reported: 2015-03-31 06:32 UTC by tyang
Modified: 2015-12-13 13:40 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
using libarchive' api when writing data to des file (2.05 KB, patch)
2015-04-22 05:51 UTC, tyang
none Details | Review
a sample of sparse file (143 bytes, application/gzip)
2015-04-22 06:31 UTC, tyang
  Details

Description tyang 2015-03-31 06:32:20 UTC
Like the title described:

The orignal file is 21.5G while the compressed tar package is 1.5G large.

I use file-roller to extract this package and find that file-roller will ignore the '-S' option when try to extract the package, so after we extract the tar package we can only get a 3.1G size file.

I also used the tar command to extract the tar package and got the correct size which it should be.
Comment 1 tyang 2015-04-22 05:51:23 UTC
Created attachment 302120 [details] [review]
using libarchive' api when writing data to des file

if we use ostream to write data to des file, we will lose some blanks which are originally stored in the src file. This should be fixed because we need to write to the target file whatever we had read especially the blank blocks which should be output to the extracted file.
Comment 2 tyang 2015-04-22 05:56:47 UTC
The attachment is my patch for this issue.

I found that these codes will prevent the file-roller from writing the blank blocks into the target file. The file-roller just ignore the blank blocks which read from the compressed sparse file. 

I think this is not right. We should completely restore the data even though the block we have read from file is a null block...
Comment 3 tyang 2015-04-22 06:31:19 UTC
Created attachment 302122 [details]
a sample of sparse file
Comment 4 Dominique Leuenberger 2015-10-28 14:50:26 UTC
Is this patch considered correct by upstream?
Comment 5 Paolo Bacchilega 2015-12-13 13:40:58 UTC
The patch was not correct.

Fixed now with commit 1149ff864d45da217d952dfbd0a45f5832f7b3bc

Thanks for reporting the bug and providing the sample file.