Re: mkisofs aborts but exit value is 0
Hi,
>>> Joerg Schilling wrote:
>>> If you like to do backups, use apropriate tools (e.g. star).
> star should handle any issue that is relevent for backups.
> Of course, star is limited to the support you get from the OS.
>
> If you find anything reasonable that is not handled correctly,
> you should send a bug report. But as star got a lot of attention
> during the past year, it should be 100% correct now. It is e.g.
> able to handle true incremental backups.
Up to now, i found a typo and a truncated sentence in the man page
of star-1.4.3 and online in
http://cdrecord.berlios.de/old/private/man/star.html :
"POSIX tar compatibilitx mode"
"The environment variable As the"
The latter is a two-liner in star.1, beginning at line 2070.
Tests are in progress. I use star as afio alternative by a
wrapper script. star option "list=-" helps to keep that
script small.
Roughly the pipeline looks like this :
my_filelist_generator | \
star -c -z list=- | \
my_checksummer | \
cdrecord ...
A question to be RTxy'ed :
Does exit 254 always indicate a incomplete but healthy
archive or are there cases where exit 254 indicates abort ?
(I got that exit value with some unreadable files in the
input list. star produced a sound archive but my own
software counted the outcome as failure because of the
non-zero exit.)
Currently i'm exploring another effect :
$ star tvf /dev/cdrom
star: Archive is compressed, try to use the -z option.
$ star tvzf /dev/cdrom
star: Can only compress files.
Possibly i should stop using old tar's command syntax ?
$ star -t -v -z f=/dev/cdrom
star: Can only compress files.
$ star -t -v -z </dev/cdrom
star: Can only compress files.
Is it a gzip'ed stream at all ?
$ gunzip </dev/cdrom | star tv
...finally my archive's table of contents...
Yes, it is.
Joerg, you seem to discourage the use of option -z
because of data block size issues, dimly remembering
me of bad old DAT times.
I never experienced such problems with cdrecord as
receiver of a gzip stream.
As one can see,
gunzip </dev/cdrom
produces a readable uncompressed star archive.
It seems a bit inconsistent that star is willing to
apply -c -z to stdout but not -t -z to stdin.
Regrettably the truncated sentence of man star is just
in the paragraph about -z. Would it give me enlightenment ?
Next i plan to learn about the incremental features.
Not so much for using them but for comparison with my
own incremental efforts.
(Imitation is the highest form of flattery.)
>> Volker Kuhlmann <hidden@paradise.net.nz> wrote:
>>
>> Not your ease of retrieval requirement. Nothing which packs up your
>> files into any sort of container first will give you easy retrieval, or
>> a lot of sleep when trying to recover the most from damaged backup
>> media. This is where creating a random-access filesystem on the backup
>> media really scores.
Yes, in rather easy situations it eases your mind.
Retrieval is as user-safe as any other file operation on a
desktop system. So my users can give such easy backups to
their users (or to their own intoxicated selves).
This does not include a system backup, of course.
Nothing is easy with the retrieval of a system backup.
Vanilla tar as found on many antique workstations isn't good enough.
I never evaluated GNU tar for 100% completeness but resort
to good old afio which serves me as Linux backup format since
more than a decade.
Nevertheless, if you have a look at the examples of star's
man page: there are some impressive stunts.
It can hardly be a mistake to offer star as backup format
to people who do system oriented backups.
> Joerg Schilling wrote :
> Something like a tar archive is easier to recover than a ISO-9660 filesystem
> where a block from a top level directory has been damaged.
As long as one does not compress the data stream, that is.
A damaged gzip stream is quite hard to recover.
There's a nice feature with afio. It offers a file-by-file
compression with cleartext archive structure.
Very rugged, quite economic.
For long time backups and extremely important data
my software offers redundancy at the level of the raw
backup data stream. The user may produce several identical
copies of the backup media which get appended a block
checksum list. This list allows to detect damaged parts of
the data stream.
By help of those checksums one can pick undamaged data
blocks from various copies ... or simply try reading these
blocks until the DVD and Linux are willing to do it right.
After a while, a readable image file may emerge on the
hard disk.
For the very cautious user i also offer permuted backup
images. Helpful when all your CDs begin to rot from the
outer edge first. (Google for "fungus eats cd".)
This feature is independent of the backup's data format
and also transparent to the reader software unless
permutation was applied. With 64 kB blocksize this needs
about 0.025% extra space on the media (1.1 MB on a 4.25 GB DVD).
The resulting media should be surveilled by checkreading
them in regular intervals, e.g. every 3 months.
> The advantage from star is that it is able to store _all_ meta data from
> a file while ISO-9660 (even with RR) only stores a limited set.
>
> No sparse files.
Here star got a very interesting advantage over afio too.
> No ACLs.
> No other file attributes.
I work around this limitation by generating list files
via getfacl and getfattr which then get included into
the backup.
On most user filesytems, ACLs and Extended Attributes are
disabled, anyway.
Have a nice day :)
Thomas
Reply to: