[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

> >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 


 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: