mkisofs aborts but exit value is 0
Hi Joerg,
i experienced an abort of mkisofs 2.01a34 which
-to my best knowledge- returned a 0 exit value.
A possible reason for this 0 exit value can be found in
the code of 2.01a34, 2.01 and 2.01.01a3 in :
mkisofs/write.c
libschily/comerr.c
The run of mkisofs aborted with these messages
19.36% done, estimate finish Tue Aug 2 08:13:49 2005
19.60% done, estimate finish Tue Aug 2 08:13:50 2005
mkisofs: Success. cannot read from '/home/th.schmitt/mail/scdbackup'
My surrounding script does notice any non-zero exit value
of mkisofs. This feature has been tested at many occasions.
This time it did not react on the abort.
So i conclude that there was a 0 exit value with mkisofs.
The reported file is a mailbox.
I looked for possible hints in mkisofs/*.c (2.01a34 to 2.01.01a3)
and found this "cannot read from" in write.c :
if (fread(buffer, 1, use, infile) == 0) {
#ifdef USE_LIBSCHILY
comerr("cannot read from '%s'\n", filename);
#else
fprintf(stderr, "cannot read from '%s'\n", filename);
exit(1);
#endif
By presuming that "mkisofs: Success." was added by comerr()
i get to libschily/comerr.c , function _comerr() ;
if (exflg) {
comexit(err);
/* NOTREACHED */
}
with comexit() finally executing exit(err).
My theory :
The mailbox file shrunk while mkisofs was trying to read it up to
the old size. fread() returned 0 because EOF was encountered before
a single byte could be read.
After this errno (resp. geterrno()) is 0. So comerr() reports "Success"
and comexit() exits with 0.
The non-USE_LIBSCHILY branch with "exit(1)" indicates that indeed
a noticeable abort is intended.
But comerr() unconditionally uses the value of geterrno() as exit value.
My wishes :
I do agree with the abort. The file in the emerging ISO image
is corrupted even if mkisofs could get itself back on track.
I would rather like to get a chance for my script to notice that abort.
An error message like "file shrunk" plus exit(1) would be fine.
As always, thanks for your work.
Have a nice day :)
Thomas
Reply to: