Re: mkisofs aborts but exit value is 0
scdbackup@gmx.net wrote:
> > 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.
>
> It opens a way to use ISO-9660 (with all pros and cons)
> as storage format. It enabled me to make use of star
> format within two hours (most of the time learning
> about star).
OK
> For example : what happens if you have to shut
> down your machine after half a backup of 50 CDs
> is done.
> Can you do the rest next day ? Without starting
> new (and not getting done until evening again) ?
If you are doing real reliable backups, you can't because
you cant't have a Filesystem snapshot that survives a reboot.
> > Does scdbackup support renamed and removed files?
>
> Yep.
...
> I'm currently learning a lot from it. I was surprised
> to see the move-detection done at restore time. That inode
> trick did not come to my mind. My solution is much
> more expensive.
> The restrictions should (and could ?) be eased, though.
Mmm, if you (as you said) do it at backup time, how do you
move that information to the restore operation?
> Would the first mail address from AN-1.5a64 be ok ?
???
> I dimly remember to have read of a mailing list
> but can't find it any more.
See star.berlios.de
> I can hardly compete, because among scdbackup's
> core properties is the rule :
> "no special tool needed for reading the backup"
> I.e. it does not demand to be present at restore time.
You don't really need anyting special to reas star's backup.
A POSIX compliant archiver is sufficient. You cannot
automatically restore the incrementals however if you
don't have star.
> > This is why all recent tape drives include "hardware" compression.
>
> Arghhhh... [author of this text fainted for a few seconds]
>
> You never know wether you get a compatible
> drive resp. firmware when you need it most.
If you have e.g. a DLT that reads the tape, it will also understand
the compression.
> It is one of _the_ arguments for backup on CD
> or DVD (although both are lousy small backup
> media).
> A DVD ROM drive is available for 20 $ everywhere.
> You can get gzip everywhere.
It may be possible (in future) to create multi volume backups via star when
you include compression in star but this is something that has low priority.
The current development goals are:
rock solid incrementals
rock solid and reliable multi volume support where it is possible
to start with any volume.
> > Mkisofs does not have a clean structure and it has not been well tested
> > when new code has been added. A major rewrite would be neccesary but this
> > could lose secret and important small things in the code.
>
> The problem is aggravated by the fact that even
> a wonderful reimplementation would not wash away
> all the old versions out there.
true
> > Padding a shrunk file is a real bad idea.
>
> To you and to me, yes.
> But not to Bill.
> He wants mkisofs to go on as long as possible.
> In a most extreme implementation :
> memset(buffer, 0, use);
> fread(buffer, 1, use, infile);
> xfwrite(buffer, use, 1, outfile, ...
>
> He got his reasons. One has to respect that.
Star does pad shrunk files because this was usual behavior
for tar long time before.
But star definitely does not mar a backup valid if this happens.
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: