Re: mkisofs aborts but exit value is 0

[scdbackup@gmx.net]

Hi,

> > Possibly one should resort to
> >   EIO              5      /* I/O error */
> This would be a bad idea.

Why that ?


> >   mkisofs: File too large. cannot read from '...'
> > might happen with a file that has 0 bytes.
> No, it may not (RTSL).

Hey ! I did invest some effort in reading the source.
You made clear in the past that RTxy is mandatory
before bothering you.


write_one_file() gets parameter  size  which
obviously is larger than the number of bytes which
fread() is finally able to deliver.
I think, this is due to the fact that the file
shrunk between the time when  size  was determined
and the time when fread() tried to read the file's
content.

write_files() seems to run a loop over a list
of  struct deferred_write  using member  size 
without determining the current file size by stat() 
or similar functions.
So if the list contains more than one member then
this opens a substantial time window for the following
prerecorded members to shrink to an arbitrary low size.
Even to 0.

In function file_write() the call of write_files()
is commented by
  /* Now write all of the files that we need. */
which makes me believe the list indeed contains
more than one file. 

The surrounding of
  (*opnt->of_write) (discimage);
in mkisofs.c does not suggest single file lists with
freshly determined file sizes either.


I could not find a spot in the code of write_one_file()
where the actual filesize 0 would be detected before the
call to fread().
But even if 0 isn't possible, there is still the
fact that the critizised file may be quite small
and that it wouldn't have failed if it was larger.


> I would need to rethink the problem.

There must be some better solution than "File too large".


Have a nice day :)

Thomas