Re: mkisofs aborts but exit value is 0
scdbackup@gmx.net wrote:
> Up to now, i found a typo and a truncated sentence in the man page
> of star-1.4.3 and online in
Any reason to test a version that is outdated since more than 3 years?
> 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.
Thank you, it seems that nobody found this 3.5 year old typos.
> Tests are in progress. I use star as afio alternative by a
afio is no real alternative to star for many reasons:
- Damaged CPIO archives are much harder to recover than
tar archives.
- The POSIX cpio format is limited to 8 GB files.
The SVr4 cpio format is even limited to 2 GB files.
- The CPIO archive format is not a single archive format
but a set of completely incompatible different formats.
- The POSIX cpio archive format is considered to be outdated
since 5 years as is is not possible to cleanly extend the
CPIO archive format. The official standard archive format
is now an extended tar format called "pax". Star is the first
program that supports this archive format and all recent
star extensions are based on this format.
- Every time afio encounters files that cannot be
processed with existing cpio archive formats, it
changes the archive format (on the fly) to a nonstandard
afio proprietary format that cannot be processed by
any other archiver.
> 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 ...
If you like to do backups, this is a really bad method.
For reliable backups, the backup utility needs to have full control
over the directory tree. This is not true in case you prepare the
filenames from another program.
> 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.)
The next release will have this text:
EXIT STATUS
The following exit values are returned:
0 All files were processed successfully.
-2 / 254
One or more files could not be processed successfully.
-1 / 255
Command line parsing error.
>0 Other positive exit codes: The errno of the call that
caused the fatal error.
> 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.
Well, star does nothing that cannot be done reliably.
As devices need to be handled in a blocked way.
This cannot be done when the in/output is run through
a zip pipe. Use star | sdd or sdd | star to reblock
the data stream in this case.
> 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.)
star-1.4 does not support incrementals.
with cpio, or a similar program, this is not possible too.
> 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.
GNU tar is not reliable enough for backups.
Every time, I added new features that supposedly is supported by GNU tar
I tested GNU tar too and I always found a bug un GNU tar after less
that 5 minutes of testing.
> There's a nice feature with afio. It offers a file-by-file
> compression with cleartext archive structure.
> Very rugged, quite economic.
Again: star does not implement things that cannot be implemented
in a reliable way. To do this, you need to knoe the compressed
size of all files before you start to archive them.
If you compress a copy in /tmp, you are limited with the size
of the files. If you do it "on the fly", you would need to compress
the file two times and still run into big problems when the file
changes meanwhile.
> 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.
For long time backups, you should not use a program like afio
that uses a proprietary achive format.
Star's archives may be unpacked by any POSIX.1-2001 compliant
archiver. If you do this, you only miss the additional
meta data from the files and you cannot do an automated incremental
restore.
> On most user filesytems, ACLs and Extended Attributes are
> disabled, anyway.
ACLs are enabled by default on the UNIX file system since
more than 10 years and cannot even be switched off.
Jörg
--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni)
schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Reply to: