Joerg Schilling wrote:
scdbackup@gmx.net wrote:Hi, many thanks for taking care of mkisofs during all the years.seterrno(EFBIG); BTW: File too large is usually used to deal with the same situationwhen 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 too small. 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 <davidsen@tmr.com> CTO TMR Associates, Inc Doing interesting things with small computers since 1979