Re: mkisofs aborts but exit value is 0
Joerg Schilling wrote:
many thanks for taking care of mkisofs
during all the years.
BTW: File too large is usually used to deal with the same situation
when writng to a device that is too small.
Do you have an idea for a better errno?
Possibly one should resort to
EIO 5 /* I/O error */
This would be a bad idea.
"File too large" is in some way the contrary
of the problem situation. Actually, the file was
Since comerr() does report the error text, this
might become quite misleading :
mkisofs: File too large. cannot read from '/home/th.schmitt/mail/scdbackup'
might happen with a file that has 0 bytes.
No, it may not (RTSL).
I would need to rethink the problem.
Here's a thought on that, if the read length is not the same as the
expected length, the error is really "file size changed during read" and
the current length can be found with stat() or similar. I'm surprised
that this doesn't come up more often, when doing backups where files
(such as logs) are growing, the available data size is growing, is that
currently handled properly?
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.
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.
bill davidsen <firstname.lastname@example.org>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979