Re: iso9660 in 1.3.6

Eric Youngdale (eric@aib.com)
Wed, 5 Jul 1995 12:17:45 -0400


On Jul 4, 2:57pm, roro wrote:
> Subject: iso9660 in 1.3.6
> Hi,
>
> alberto.vignani@pmn.it reported on linux-gcc problems (directory
> listings) with iso9660. This patch works for me - can be wrong.
> But somebody should clean the mess. (Who wrote this?:
> /*
> * This should _really_ be cleaned up some day..
> */
> )

I was looking over the patch that you submitted, and I am having
trouble seeing why this patch corrects a corrupt directory listing problem.
It appears to me that the existing code should have been able to treat the
case you are dealing with, and I am wondering if you can provide me with
more information. I am aware that something like this patch is probably
needed because we will be accessing beyond the end of the buffer (and hence
into some other unrelated page of memory), so some fix is required, but I
would like to understand this some more.

Could you tell me why this section of code:

/* Make sure that the entire directory record is in the
current bh block.
If not, put the two halves together in "tmpde" */
next_offset = offset + de_len;
if (next_offset > bufsize) {
next_offset &= (bufsize - 1);
memcpy(tmpde, de, bufsize - offset);
brelse(bh);
block = isofs_bmap(inode, (filp->f_pos + de_len) >>
bufbits);
if (!block)
return 0;
bh = breada(inode->i_dev, block, bufsize,
filp->f_pos+de_len, inode->i_size);
if (!bh)
return 0;
memcpy(bufsize - offset + (char *) tmpde,
bh->b_data, next_offset);
de = tmpde;
}
offset = next_offset;

was not able to deal with the problem? From what I can tell, this
should have detected that we were reading at or beyond the end of
a buffer, and thus it should have been doing the right thing.

-Eric

-- 
"The woods are lovely, dark and deep.  But I have promises to keep,
And lines to code before I sleep, And lines to code before I sleep."