Re: mkisofs aborts but exit value is 0
Bill Davidsen <davidsen@tmr.com> wrote:
> >It's just that a reasonable person does not backup agile
> >parts of the disk via mkisofs directly. (I was doing an
> >experiment for evaluating a user's error message. So i
> >did things which i never had done on my own before.)
> >
> >
>
> Unless you have the luxury of taking the system to single user mode, it
> is always possible that you should have a file change. But in the case
> of a moving target you are always taking a snapshot in time of the data,
> and therefore robust behaviour is desirable, since you always backup
> /then/ rather than /now/. I would be perfectly happy to have the file
> truncated or ignored, but having the backup fail, particularly without
> an error status, is just the mark of clumsy programming.
Filesystem Snapshot support is available since nearly 4 years now, and
doing a backup without a snapwhot today means ignoring all experiences
about backup problems.
There is no need to bring a machine down these days unless you are running
an unsuited OS.
> >>mkisofs is not a backup tool.
> >>
> >>
> >
> >It is not an appropriate tool for general backup situations.
> >
> >
> But it is virtually the only suitable tool for general portability
> between hardware and O/S environments. And for general backup, it offers
As is star.....and in contrary to mkisofs, star is a backup program.
> far faster access to files it the most common case, that in which a
> small number of files must be restored. Since no list of files to ignore
> can be complete for more than a point in time, and there's currently no
> option in mkisofs (or any other widely used backup) to just mark any
> file which has changed as zero length but preserve ownership and
???? Could you explian what this should mean?
> DAT tapes (still use them for compatibility) were fine for saving and
> restoring a load of data as an indivisible unit. As you imply and I
> agreed above, any sequential data format is undesirable for applications
> requiring access to individual files.
DAT tapes were never fine for backups because they did give you a very limited
reliability.
> >I will have to RTxy about star in order to find out
> >which of the challenges of backuping it promises to
> >handle.
> >
> >
> I would have loved to have star 15 years ago. I wouldn't use *any*
> solution today which required reading the whole data set to extract
> things, was not portable, and which is not cost effective in terms of
As star uses a POSIX compliant archive format and as star is higly portable,
the backups made with star are of course portable.
> timeto recovery. Star represents the best implementation ever written of
> an obsolete method of backup, and I can't think of any reason other than
> "someone paid me to do it" why I would use star or any similar thing for
> backup.
Mkisofs is unsuitable for backups and it is bad to see that people believe
otherwise.
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: