Re: mkisofs aborts but exit value is 0
Hi,
>> scdbackup@gmx.net wrote :
>> my own software is the backup utility and star is the
>> media image formatter
> Joerg Schilling 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).
The design of planner-executor-formatter-writer
solves quite a bunch of real world problems.
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) ?
I confess, it does create new problems, too.
That keeps me busy.
>> i 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.
I can make good use of star reporting problem files and
issueing this exit hint to the wrapper. The wrapper (in its
role as formatter) forwards the hint to the executor
which gives the user a heads-up when the next media is
prompted. A terminal window with big scrollback buffer
is helpful to see all messages.
It seems to do very well as it is.
> Does scdbackup support renamed and removed files?
Yep.
> Star does. It does even in a very efficient way.
True.
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.
I'm in the process of adopting the idea of inode tracking.
Not at restore time but rather at backup time.
This shall (hopefully) avoid restrictions in respect
to partial backups (dumps) or to active mount points at
restore time. (Restrictions which currently don't apply
to scdbackup and shall not apply to it in future.)
You'll get a report about my encounter with star at
a more appropriate place.
If i don't fail miserably, that is.
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.
> Star includes consistensency checks at restore time and warns
> you if you try to restore the wrong archive or use the
> wrong order.
Its high degree of integration makes it look
very good at this point.
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.
(One can discuss wether reader software for the
backup format is a 'special tool' but in case
of ISO-9660 most people aren't aware that there
is any reader software.)
> 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.
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.
The only thing to worry about is the readability of
your media.
My oldest checksummed CD-RW set is 32 months old
and i do verify it every 3 months. Not a single
loss out of 60 media up to now. (That backup is
totally outdated of course)
DVD+/-RW i watch since about a year.
> ACLs have been (silently) enabled on Solaris since 1994.
I was surprised to be asked about ACL backup by a
user and my stupid answer was that i had no fancy
filesystems for testing.
He pointed me to man 8 mount and i had to learn
that even ext2 is able to handle ACLs.
Luckily he also pointed me to man 1 getfacl .
Now i keep a pet ACL filesystem for tests.
> 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.
mkisofs is as it is. :)
You can remove its bugs. But as an application
programmer i will still have to live with them
for quite a while. They became part of the users'
operating systems.
A rewrite should have a new name. As the
manpage of mkisofs states : even its name
is kindof a bug. (re: "mkproto")
And could somebody please rewrite scdbackup, too ?
I'm too busy with introducing new gimmicks.
> 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.
Have a nice day :)
Thomas
Reply to: