Hi, > 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 question. > 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 errctl= name > [having the backup fail] particularly without an error > status, is just the mark of clumsy programming. It is a bug. We all deliver bugs. 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 raise my hat in front of his endurance. > 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. > 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. :))) > 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 prerequisites. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
