diff options
author | Robin H. Johnson <robbat2@gentoo.org> | 2015-08-08 13:49:04 -0700 |
---|---|---|
committer | Robin H. Johnson <robbat2@gentoo.org> | 2015-08-08 17:38:18 -0700 |
commit | 56bd759df1d0c750a065b8c845e93d5dfa6b549d (patch) | |
tree | 3f91093cdb475e565ae857f1c5a7fd339e2d781e /app-arch/lziprecover/metadata.xml | |
download | gentoo-56bd759df1d0c750a065b8c845e93d5dfa6b549d.tar.gz gentoo-56bd759df1d0c750a065b8c845e93d5dfa6b549d.tar.bz2 gentoo-56bd759df1d0c750a065b8c845e93d5dfa6b549d.zip |
proj/gentoo: Initial commit
This commit represents a new era for Gentoo:
Storing the gentoo-x86 tree in Git, as converted from CVS.
This commit is the start of the NEW history.
Any historical data is intended to be grafted onto this point.
Creation process:
1. Take final CVS checkout snapshot
2. Remove ALL ChangeLog* files
3. Transform all Manifests to thin
4. Remove empty Manifests
5. Convert all stale $Header$/$Id$ CVS keywords to non-expanded Git $Id$
5.1. Do not touch files with -kb/-ko keyword flags.
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
X-Thanks: Alec Warner <antarus@gentoo.org> - did the GSoC 2006 migration tests
X-Thanks: Robin H. Johnson <robbat2@gentoo.org> - infra guy, herding this project
X-Thanks: Nguyen Thai Ngoc Duy <pclouds@gentoo.org> - Former Gentoo developer, wrote Git features for the migration
X-Thanks: Brian Harring <ferringb@gentoo.org> - wrote much python to improve cvs2svn
X-Thanks: Rich Freeman <rich0@gentoo.org> - validation scripts
X-Thanks: Patrick Lauer <patrick@gentoo.org> - Gentoo dev, running new 2014 work in migration
X-Thanks: Michał Górny <mgorny@gentoo.org> - scripts, QA, nagging
X-Thanks: All of other Gentoo developers - many ideas and lots of paint on the bikeshed
Diffstat (limited to 'app-arch/lziprecover/metadata.xml')
-rw-r--r-- | app-arch/lziprecover/metadata.xml | 47 |
1 files changed, 47 insertions, 0 deletions
diff --git a/app-arch/lziprecover/metadata.xml b/app-arch/lziprecover/metadata.xml new file mode 100644 index 000000000000..eb4dc77430b4 --- /dev/null +++ b/app-arch/lziprecover/metadata.xml @@ -0,0 +1,47 @@ +<?xml version="1.0" encoding="UTF-8"?> +<!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd"> +<pkgmetadata> + <maintainer> + <email>polynomial-c@gentoo.org</email> + <name>Lars Wendler</name> + </maintainer> + <longdescription lang="en"> + Lziprecover is a data recovery tool and decompressor for files in the lzip + compressed data format (.lz), able to repair slightly damaged files, + recover badly damaged files from two or more copies, extract data from + damaged files, decompress files and test integrity of files. + The lzip file format is designed for long-term data archiving. It is clean, + provides very safe 4 factor integrity checking, and is backed by the + recovery capabilities of lziprecover. + Lziprecover is able to recover or decompress files produced by any of the + compressors in the lzip family; lzip, plzip, minilzip/lzlib, clzip and + pdlzip. + Lziprecover makes lzip files resistant to bit-flip (one of the most common + forms of data corruption), and can safely merge multiple damaged backup + copies. + If the cause of file corruption is damaged media, the combination GNU + ddrescue + lziprecover is the best option for recovering data from multiple + damaged copies. + If a file is too damaged for lziprecover to repair it, all the recoverable + data in all members of the file can be extracted with the '-D' option. + Lziprecover is able to efficiently extract a range of bytes from a + multi-member file, because it only decompresses the members containing the + desired data. + Lziprecover can print correct total file sizes and ratios even for + multi-member files. + When recovering data, lziprecover takes as arguments the names of the + damaged files and writes zero or more recovered files depending on the + operation selected and whether the recovery succeeded or not. The damaged + files themselves are never modified. + When decompressing or testing file integrity, lziprecover behaves like lzip + or lunzip. + To give you an idea of its possibilities, when merging two copies, each of + them with one damaged area affecting 1 percent of the copy, the probability + of obtaining a correct file is about 98 percent. With three such copies the + probability rises to 99.97 percent. For large files (a few MB) with small + errors (one sector damaged per copy), the probability approaches 100 percent + even with only two copies. + Lziprecover is not a replacement for regular backups, but a last line of + defense for the case where the backups are also damaged. + </longdescription> +</pkgmetadata> |