Re: mkisofs aborts but exit value is 0
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.)
> 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.
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 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.
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.
Have a nice day :)
Thomas
Reply to: