[Top][All Lists]

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

Re: [Bug-tar] tar fails to preserve hard links with --remove-files

From: Andreas Dilger
Subject: Re: [Bug-tar] tar fails to preserve hard links with --remove-files
Date: Fri, 31 Jul 2009 01:06:36 -0600
User-agent: Mutt/1.5.18 (2008-05-17)

On Jul 30, 2009  04:57 -0700, Carl Worth wrote:
> On Sun, 13 Apr 2003 15:45:27 -0400, Theodore Ts'o <address@hidden> wrote:
> > I'm pretty sure, by the way, that the problem is that tar is keying
> > off of the st_nlink to decide whether or not to do hard link
> > processing as an optimization.  When --remove-files is present, then
> > st_nlink of the hard-linked inode is dropping, and when st_nlink is
> > one, tar can't tell that it was previously a hard-linked file.  The
> > fix would require that tar check every single file's inode number
> > against previously written files to see if it was a hard linked file
> > (instead of just checking files where st_nlink > 1), in the case when
> > --remove-file option is in use.
> I've attached two patches to fix this bug. The first implements Ted's
> suggestion, (using the hard links hash table for all files when the
> --remove-files option is in effect, regardless of the value of
> st_nlink). The second patch adds a test case for the bug, (failing
> before the first patch is added and passing afterwards).

Rather than do a lookup of every file in the filesystem in the hard
link table ($num_files lookups in the hash table) it would probably be
more efficient to "save" the second-last link to the file, mark the
hash table entry with "delete on next link", and when the last link is
found unlink both of them at once.  That would avoid hash lookups
for 99% of the files in the archive (if assuming typical hard link

Cheers, Andreas
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.

reply via email to

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