Re: mkisofs aborts but exit value is 0

[Bill Davidsen <davidsen@tmr.com>]

scdbackup@gmx.net wrote:

Hi,

  

Bill Davidsen wrote:

Since I never get an error I would suspect that the change is not 
detected, the only question is if the data saved is only that which was 
originally expected, or all available.
    

To my theory the effect should occur whenever  filesize div 32768
yields a lower result at reading time than at the time when
the extends were scheduled. 
It is not very unlikely to happen, but up to now it resulted
in a silent abort of mkisofs. 

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.

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.
    

I considered to propose Joerg a stat() before fopen().
But shrinking is not the only menace for a file in this
situation. There may occur any kind of content inconsistency
if a file changes while it is copied.

My next idea was to propose MD5 sums generated at scheduling
time. But that would imply to read the files twice and
still would not close all time windows for inconsistencies
and race conditions.
  

I seriously doubt thaere's a totally satisfactory way to do this, however a stat and compare of the mtime would catch files which are likely to be an issue, although obviously not every possible case.

So i think it's best if mkisofs only cares for its own
survival in respect to readability of files.
I appreciate if it aborts on obviously dangerous changes
but do not rely on that fact. And i tell my users not to
do so either.

>From the point of view of mkisofs it might even be a
better behavior not to abort at all but to pad up the
missing bytes. (This is done currently inadvertedly if 
the shrinking does not change the filesize div 32768.)

It would be an elegant way to avoid the need to invent
an appropriate pseudo error.


  

Joerg Schilling wrote :

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 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 permissions, it is useful in most general backup situations as well.

But it produces very versatile backups of user data files,
especially of home directory trees and multi-media collections.
With such data it solves two very old and very annoying problems
of classical backups : ease of retrieval and subjective trust.

Ease of Retrieval :
Good backup media got big capacity and therefore long
runtimes. Good general backup formats usually got a sequential
structure and therefore require scanning of a substantial
part of a backup volume in order to retrieve a file.
With a DVD, such a scan run can last 5 to 10 minutes.
Reminds me of the bad old times of DAT tapes.
  

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.

Subjective Trust:
Speaking of the bad old DAT times : how could one make sure
for oneself (not for the checkread mode of the backup software)
that this backup will be usable in case of emergency ?
>From time to time i have to explain users that it is *not* an
appropriate test for a backup to restore it over the healthy
production files. Most of them wish a less dramatic way to
get a good feeling about their backup, though.
And here mkisofs is great. You can open the files with
the application software which knows how to handle them and
which (hopefully) can tell you wether they are undamaged.
Different from other filesystems (like ext2) there is a
convenient way to generate ISO images on the fly.

Yes. mkisofs is a bit pre-alpha in certain situations
which occur often in certain system directories. But
in other situations which occur often with real life user
directories, it was a revolutionary opportunity for backups
when i encountered it in the late 1990s.
A mountable random access backup that *works*. Gosh.


  

If you like to do backups, use apropriate tools (e.g. star).
    

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

Have a nice day :)
  

I fear that neither your opinion nor mine will improve Jǒrg's day. I'm sorry about that, but people use software which does what they need, not something neat but unsuitable.

-- 
bill davidsen <davidsen@tmr.com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979