[Bug-tar] --backup can destroy an extracted member when followed by an existing directory

[Carl Worth]

On Mon, 08 Dec 2008 13:41:57 -0500 Eric Lammerts wrote:
> When extracting, tar sometimes renames a backup back to the original name
> (overwriting the newly-extracted file) for no good reason.
> 
> Example:
> # mkdir dir1 dir2
> # echo bla > dir1/file1
> # tar cf test.tar dir1 dir2
> # tar xfv test.tar --backup
> dir1/
> dir1/file1
> Renaming `dir1/file1' to `dir1/file1~'
> dir2/
> Renaming `dir1/file1~' back to `dir1/file1'
> 
> This problem is made worse by the fact that if you do the above with "tar
> xf" instead of "tar xfv", tar doesn't print anything at all (and exits
> with status 0)!! Failure to extract a file should be an error, not just a
> message printed only in verbose mode.

Hi Eric,

Thank you for the bug report against the Debian tar package. I've
verified that this bug also exists in tar version 1.22-1.1 as packaged
by Debian.

I've traced through the code a bit and the problem is due to the
handling of directory entries in extract.c:extract_archive(). Here is
what happens when processing dir2 in the above scenario:

1. maybe_backup_file() returns true, but without changing
   after_backup_file (which was set previously to dir1/file1~)

2. extract_dir(), (called through *fun) returns -1 since the
   directory already exists

3. after detecting that an archive member failed to extract, the code
   calls undo_last_backup() to restore the backup. However, at this
   point the file names after_backup_file and before_backup_file still
   correspond to dir1/file1~ and dir1/file1 due to step #1.

So step 1 is definitely a bug, and step 2 might potentially be a bug as
well. I've attached a simple patch to fix the bug in step 1. Sergey,
perhaps you'll have a cleaner fix. Please let me know.

-Carl

0001-maybe_backup_file-Clear-previously-set-after_backup_.patch
Description: Text Data

signature.asc
Description: This is a digitally signed message part