Re: mkisofs aborts but exit value is 0
scdbackup@gmx.net wrote:
> > - Damaged CPIO archives are much harder to recover than
> > tar archives.
>
> afio does a good job with that.
But this is very time consuming as it needs to step forward
in 2 byte units while tar may do it in 512 byte units.
> > - The POSIX cpio format is limited to 8 GB files.
> > The SVr4 cpio format is even limited to 2 GB files.
>
> I urge my users not to store files larger than 2 GB
> in any backup format. Such a size makes readability
> questionable. Not only because of the reader software
> but also because of the rest of the reading system's
> infrastructure.
While this may have been true 1995 when the first large file
support appeared on UNIX, it is no longer true today if you
use the right backup tools.
> Well, in this scenario my own software is the backup
> utility and star is the media image formatter (like
> afio, mkisofs, zip or whatever).
If you do this with mkisofs or afio which are no backup
tools, this may be OK, but if you do this with a program like star
that includes backup support, it is questionable.
> Very good. It's rare that command line utilities
> specify their exit values.
> I meanwhile had found that exit(-2); in star.c
> and dared to make my wrapper handle 254 as
> a non-perfect but overall successful program run.
If you know that there may be tolerable problems, it is better
to use the errctl= option and to tell star to ignore this
special condition.
> > star-1.4 does not support incrementals.
> > with cpio, or a similar program, this is not possible too.
>
> But with scdbackup it's possible :))
> Incremental ISO, incremental afio, incremental star-1.4 ...
> on a file-by-file level, not on a rsync level.
Does scdbackup support renamed and removed files?
Star does. It does even in a very efficient way.
> Nevertheless one has to warn users of the increase in
> complexity which is caused by an incremental backup
> scheme.
> It is very convenient at backup time but may cause
> a lot of extra work at restore time.
Star includes consistensency checks at restore time and warns
you if you try to restore the wrong archive or use the
wrong order.
> Anyway, compression is nearly a must with large backups
> of system oriented files. Sysadmins tend to hate waste of
> media and of time. Especially if they have to change the
> media every few minutes.
This is why all recent tape drives include "hardware" compression.
> > ACLs are enabled by default on the UNIX file system since
> > more than 10 years and cannot even be switched off.
>
> At least for SuSE Linux it is necessary to add options
> to /etc/fstab . This is specific to the particular file
> system type. With reiser or ext2 this would be option "acl".
ACLs have been (silently) enabled on Solaris since 1994.
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: