You could be right, I assumed it was a design decision. I may be
sensitized since I find that I disagree with him moderately often. I
guess from discussions elsewhere I'm not totally alone in that :-(
Bill Davidsen wrote:
Unless you have the luxury of taking the system to single user mode, it
is always possible that you should have a file change.
Yep. The backup should be done in situations where
changes either don't occur or don't matter for the
quality of the backup.
How to achieve such a situation is a very individual
I would be perfectly happy to have the file truncated or
ignored, but having the backup fail,
This depends much on the backup data's needs.
Interestingly, most backup tools seem to share your opinion.
My special favorite afio does it, too.
Joerg's star looks promising with option
[having the backup fail] particularly without an error
status, is just the mark of clumsy programming.
It is a bug. We all deliver bugs.
Yes, and that's too bad. If he took suggestions in better ways, perhaps
that could change. Several people have commented that they didn't try
"alpha" versions when comparing production software, because virtually
everyone other developer uses alpha for "try at your own risk"
and a more reassuring term like beta or release candidate
for stuff which you might want to use.
Since quite a lot of years we have to be thankful
to Joerg Schilling who provides the only general
ISO-9660 formatter and CD-RW writer software for
Linux systems of nearly any age.
Although he seems not to enjoy it much.
I have never understood his motivation, the last time I tried to
actually buy the "pro" stuff he didn't take credit cards or paypal, so
he surely isn't motivated by profit! So we have three hacks of his
software for DVD, which is also sad.
I raise my hat in front of his endurance.
No guess, he took it over from someone else, and while he might accept
patches I doubt he would give up control.
I suggest that if the size changes during backup it should be noted but
should not be a fatal error, since mkisofs is used on live data and
should be robust in practice.
mkisofs is as it is. I do not dare to make too many
detailed suggestions. The risk is high to end up as
its maintainer. I suspect Joerg to be just waiting
for somebody with a mouth too big.
Perhaps if you don't mind the chance at public rejection you might
offer that patch, I would happily patch the current behaviour.
a stat and compare of the mtime would catch files which are likely to be
an issue, although obviously not every possible case.
Actually the affected read loop would need a fallback
padding in case it cannot read the number of bytes
which it announced in the directory structure.
This directory is already written to the resulting
ISO image at the time when the fread() occurs. No
chance to correct it if you don't want to break
mkisofs' capability to put the result to stdout.
The padding would be quite easy to implement.
It is already nearly complete by incident.
Just a few more little ifs here and a little
variable there. :)))
>From memory there was another tool called something like mondo backup
which also did that. But once you understand how the boot stuff works
you can take that floppy image and get enough stuff into it to roll
your own bootable CD. After that you could partition the disk and
actually pull the files from a tar/star/afio/cpio backup. I confess
that if I actually do use any streaming backup I usually use cpio with
the -Hcrc (crc per file) option. I have not quantifiled the recovery
capabilities other than "adequate for what I've needed" nor do I use it
where I care about ACLs, capabilities, or any other extensions.
The issue raised is that star backups are not bootable on any machine
I've found, and are unsuitable for "system backups" for that reason. ISO
CDs are bootable on many machines, and AIX on IBM hardware supports
making bootable backup, which is what I was thinking for a system backup.
There is a similar tool for Linux named mkCDrec.
It combines a standalone CD-Linux with tar-archives.
Of course, mkisofs and cdrecord are among its
bill davidsen <firstname.lastname@example.org>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979