[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-cpio] upgrade path from 8 GB limit?
From: |
J Martin Rushton |
Subject: |
Re: [Bug-cpio] upgrade path from 8 GB limit? |
Date: |
Wed, 30 Mar 2016 17:29:38 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Be careful with cpio restores. There has been a change in behaviour
and recent cpios will respect the leading slash of a full disk instead
of stripping it. The result is that a restored tree is replaced where
it came from, not based on where your default currently is (as the
documentation shows). If you pull back an archive and expand it to
recover an old version of a file you may overwrite your entire disk.
Martin
On 30/03/16 16:37, Abner Gershon wrote:
> I recently re-evaluated my backup strategy. After using tar for
> years I did some side by side comparisons between cpio and tar with
> regard to recovering damaged archives. I found that cpio was more
> reliable in this regard. In fact even though tar is quite familiar
> to me I find the cpio command line more intuitive. For these
> reasons i would like to switch to cpio to archive my data to
> magnetic tape (LTO). With the exception of single disk image file
> on my server none of the other files even come close to the 8 GB
> limit of the ustar format. I am just wondering if anyone is
> currently working on a path to allow for backup and restore of
> files larger than 8 GB?
>
> BTW thank you to everyone that is involved with creating or
> maintaining this piece of software.
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJW+/7xAAoJEAF3yXsqtyBle+sQAMFJ8Wx4TUMeN/ww06myISCI
1sAqy+r29e+Ew75i87h2APMGiawH6KaKWn/Atn/t+d2rgTpXpwRweXbYCEqK7V0k
yzMkE4zWOP/y4ojb89D5ftnmad/H3I7LeCmmT2aeU/XmyL37QsxU41QLSfJCFZcv
nWDK0+3hs/Gyi4oOEIa+yFjyz5H9YTGyGXQMi70O3EU/DcyXuEU1hFbkGXGRaoXe
rc/PEy1Oqu9vfZmWfy5A/Roga204hZuOF1piROitvNRjFCKGe1pZyEzIn22+csDZ
dA89Sy4eo9t+nUu4ljVKJIYzcMY3ubPaJa9vBtaMwAPJdqd0YXw/tFbVUa37c9ga
A+9vfe62bdWV54/szh9kCciJgXLUJE5h+XvDWBANqNYipG+POhyrZbIU63dbyGPC
a3awzmVTV69Noq4H9RBN63pWzxVKvRF6LlHnjAbU6mhbhy9ysqPwoM3W2bqM4bLv
GwRPbcXiBGYAC5o7P+f4vdxHOgcqLp+IISWFzHD1RkA6brqCqpd19859Z9IEp2/T
6P3H21EM8OiI8C/1oF3VuTZVs8Ym4g86g38Qyfa94LPYZtuZBDFYNqEE6MpdVS8u
d8UHj8RLoLKA6gpBXiQ0Zr1zhGrj0h0KRRYCesT38+5vbCgpUW6CQ115wlB347WM
AMcCktbA27kgd6KG53bo
=XRse
-----END PGP SIGNATURE-----