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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
