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>

---

Pekka Enberg correctly pointed out that there was a similar change made to

parse_rock_ridge_inode_internal() that should also be reverted.  Please

ignore

my previous patch, and use this patch instead.  Thanks Pekka!

--- linux-2.6.26/fs/isofs/rock.c.orig   2008-07-13 11:51:29.000000000 -1000

+++ linux-2.6.26/fs/isofs/rock.c        2008-07-15 21:52:43.000000000 -1000

@@ -209,6 +209,9 @@ repeat:
        while (rs.len > 2) { /* There may be one byte for padding

somewhere */

                rr = (struct rock_ridge *)rs.chr;

+               /* Ignore rock ridge info if rr->len is out of range, but

+                  don't return -EIO because that would make the file

+                  invisible. */

                if (rr->len < 3)

                        goto out;       /* Something got screwed up here */

                sig = isonum_721(rs.chr);

@@ -216,8 +219,9 @@ repeat:

                        goto eio;

                rs.chr += rr->len;

                rs.len -= rr->len;

+               /* As above, ignore rock ridge info if rr->len is bogus. */

                if (rs.len < 0)

-                       goto eio;       /* corrupted isofs */

+                       goto out;       /* Something got scr...
[ message continues ]

Hi Adam,
Looks good to me.
Reviewed-by: Pekka Enberg <penberg@cs.helsinki.fi>
--