Hi Adam,

On Wed, Jul 16, 2008 at 7:41 AM, Adam Greenblatt
<adam.greenblatt@gmail.com> wrote:
quoted text
> Some iso9660 images contain files with rockridge data that is either
> incorrect or
> incompletely parsed.  Prior to commit
> f2966632a134e865db3c819346a1dc7d96e05309,
> (included with kernel 2.6.13) the kernel ignored the rockridge data for
> these files,
> while still allowing the files to be accessed under their non-rockridge
> names.  That commit
> inadvertently changed things so that files with invalid rockridge data could
> not be accessed
> at all.  (I ran across the problem when comparing some old CDs with hard
> disk copies I had
> made long ago under kernel 2.4: a few of the files on the hard disk copies
> were no longer
> visible on the CDs.)
>
> This change reverts to the pre-2.6.13 behavior.
>
> Signed-off-by: Adam Greenblatt <adam.greenblatt@gmail.com>
> ---
> --- linux-2.6.26/fs/isofs/rock.c.orig   2008-07-15 18:19:36.000000000 -1000
> +++ linux-2.6.26/fs/isofs/rock.c        2008-07-15 18:16:56.000000000 -1000
> @@ -217,7 +217,7 @@ repeat:
>               rs.chr += rr->len;
>               rs.len -= rr->len;
>               if (rs.len < 0)
> -                       goto eio;       /* corrupted isofs */
> +                       goto out;       /* corrupted isofs */
>
>               switch (sig) {
>               case SIG('R', 'R'):

I suppose you want to fix parse_rock_ridge_inode_internal() also for
consistency and add a comment there why we don't fail for that case.
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/