bug-tar
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-tar] gnu tar: Sparse Bug


From: Sergey Poznyakoff
Subject: Re: [Bug-tar] gnu tar: Sparse Bug
Date: Thu, 28 Aug 2003 20:51:00 +0300

Hi Andrew,

> It seems that I have come across a bug in the sparse functionality, though
> it may only affect people doing wierd things with tar like I am. Tar
> incorrectly extracts files that were tar'ed with the -S (sparse) option.
> From the many tests that I have done, I can see that tar does not write the
> blocks of zeros to replace the sparseness. Instead it seems that it simply
> jumps over the 0 blocks. 

Yes, it does. The "sparseness" of the file is detected by analyzing the
size of the file reported by the stat() call and the number of file
system blocks actually allocated for it. If this number is less
than what whould be needed to accomodate the reported file size, tar
assumes that the file has unused "holes" in it.

When extracting, tar skips over the holes on the assumption that
they are never used, and in order for the created file to have
the same number of blocks as its original version (in other words,
the created file will also be sparse).

> I have come up with modifications that correct the problem. However, the
> changes increase the extraction time significantly for sparse files. Its
> possible that there may be a more efficent way to implement a fix, but since
> the fix requires a write instead of an lseek, increase in extraction time is
> necessarily a consequence. 

I understand the idea. However, the file thus created will not be sparse
anymore. On the other hand, if it is created using the current
algorithm and the skipped blocks are not filled with nulls, the
subsequent attempt to archive it with -S flag will also fail...
 
>       Im not sure if the fix should be standard, or only used with the
> "--block-dev-contents" flag, because Im unaware if this probelem could show

Yes, probably. Anyway, the sparse handling algorithm needs to be revised.
Thanks a lot for raising this issue.

Regards,
Sergey




reply via email to

[Prev in Thread] Current Thread [Next in Thread]