Re: [Bug-tar] Incremental restore seems to first create then rename

[Felix E. Klee]

On Sat, 11 Sep 2004 20:33:09 +0200 Helmut Waitzmann wrote:
> >I assume that this error is caused because tar tries to create the new
> >file before doing the renaming.
> 
> I assume, that tar does no renaming at all.  To know that for certain,
> look at the file list of "2.tar".  The file 2store/B/a is an archive
> member, and so is 2store/B, isn't it?  

You're right:

[...]> tar tf 2.tar
2store/
2store/B/
2store/A
2store/B/a

What follows is an excerpt from tar's info page. It states that a
directory whose name has changed is stored during incremental backups
(information is missing that the same applies to ordinary files,
BTW). This is a severe disadvantage of tar as a backup tool.

   The file, which is archive independent, contains the date it was last
modified and a list of devices, inode numbers and directory names.
`tar' will archive files with newer mod dates or inode change times,
and directories with an unchanged inode number and device but a changed
directory name.  The file is updated after the files to be archived are
determined, but before the new archive is actually created.

> So, what tar tries to do is:
> (1) remove the file 2store/A (which fails, because 2store/A is a directory,
>     not a file),
> (2) create a file 2store/A (which fails, because 2store/A exist already
>     and is a directory),
> (3) create a directory 2store/B and a file 2store/B/a (which successes).

This explanation doesn't seem to be correct. When I don't create the
text file 2store/A in between backups, the directory is deleted upon
restoring 2.tar. Here's some verbose output from tar, illustrating this
case:

2store/
tar: Deleting `2store/A'
2store/B/
2store/B/a

In the case that the text file A is created in between backups (see my
original script), then I get the following verbose output upon restoring
2.tar. It seems that tar tries to create the file 2store/A before
removing the directory of the same name. To me, this looks like an
obvious bug: Directories should be removed before files are created.

2store/
2store/B/
2store/A
tar: 2store/A: Cannot open: File exists
2store/B/a
tar: Error exit delayed from previous errors

> I don't know, whether option "--recursive-unlink" could help.  But
> beware!  Quoting the tar info:(tar)Recursive Unlink:
> 
> [...]

As can be inferred from the documentation, this option is not applicable
for incremental restores: If the contents of a directory are only
partially updated during a restore, then files is lost. For example,
suppose that the text file 2store/C/y is added before the second backup,
but the text file 2store/C/x is left unchanged. When restoring the data
incrementally, then 2store/C/x is deleted during the "recursive unlink
phase" of the second restore. See also the attached script, which
illustrates that problem.

Anyways, I'll look for a tool that does not backup entire directories,
if they have only been moved since the last backup. Discovering such
cases should be possible by looking at the inode number and the
modification time: If the inode number and the modification time of a
directory is identical to one stored in a previous backup, then those
directories are identical. If the paths are different, then a move
should take place upon restore.

Felix

run2
Description: Binary data