Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 18 Jan 2008 08:29:02 -0500
From:      John Baldwin <jhb@freebsd.org>
To:        Tim Kientzle <kientzle@freebsd.org>
Cc:        cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org
Subject:   Re: cvs commit: src/lib/libarchive archive_write_disk.c src/lib/libarchive/test Makefile test_write_disk_hardlink.c
Message-ID:  <200801180829.03092.jhb@freebsd.org>
In-Reply-To: <200801180505.m0I55woO042844@repoman.freebsd.org>
References:  <200801180505.m0I55woO042844@repoman.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 18 January 2008 12:05:58 am Tim Kientzle wrote:
> kientzle    2008-01-18 05:05:58 UTC
> 
>   FreeBSD src repository
> 
>   Modified files:
>     lib/libarchive       archive_write_disk.c 
>     lib/libarchive/test  Makefile 
>   Added files:
>     lib/libarchive/test  test_write_disk_hardlink.c 
>   Log:
>   Issues with hardlinks in newc-format files prompted me to
>   write a new test to exercise the hardlink strategies used
>   by different archive formats (tar, old cpio, new cpio).
>   This uncovered two problems, both fixed by this commit:
>   
>   1) Enforce file size when writing files to disk.
>   
>   2) When restoring hardlink entries, if they have data associated, go
>      ahead and open the file so we can write the data.
>   
>   In particular, this fixes bsdtar/bsdcpio extraction of new cpio
>   formats where the "original" is empty and the subsequent "hardlink"
>   entry actually carries the data.  It also provides correct behavior
>   for old cpio archives where hardlinked entries have their bodies
>   stored multiple times in the archive; the last body should always be
>   the one that ends up in the final file.  The new pax format also
>   permits (but does not require) hardlinks to carry file data; again,
>   the last contents should always win.
>   
>   Note that with any of these, a size of zero on a hardlink simply means
>   that the hardlink carries no data; it does not mean that the file has
>   zero size.  A non-zero size on a hardlink does provide the file size.
>   
>   Thanks to: John Baldwin, for reminding me about this long-standing bug
>       and sending me a simple example archive that prompted this test case

Woo, thanks!

-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200801180829.03092.jhb>