[iso9660] PANIC: could not read block 200333: bytesRead: -1, error: Invalid Argument

[diver]

This is hrev42598, gcc2hybrid.

I'm running into this panic after mounting iso9660 session of "New English File Upper-intermediate MultiROM" and opening it in Tracker.

KERN: ISOMount - ENTER
KERN: B_GET_PARTITION_INFO: ioctl returned error
KERN: ISOMount: open device/file "/dev/disk/atapi/1/master/1"
KERN: ISOMount: Is an ISO9660 volume, initting rec
KERN: InitVolDesc - ENTER
KERN: InitVolDesc - system id string is APPLE COMPUTER, INC., TYPE: 0002
KERN: InitVolDesc - volume id string is OUP
KERN: InitNode - ENTER, bufstart is 0x8147ca4d, record length is 34 bytes
KERN: InitNode - ext attr length is 0
KERN: InitNode - data start LBN is 200299
KERN: InitNode - data length is 2048
KERN: InitNode - flags are 2
KERN: InitNode - fileUnitSize is 0
KERN: InitNode - interleave gap size = 0
KERN: InitNode - volume seq num is 16777217
KERN: InitNode - file id length is 1
KERN: DirRec ID String is: .
KERN: RR: Start of extensions at 0x8147ca6e
KERN: InitVolDesc - volume set id string is NOT_SET
KERN: InitVolDesc - volume pub id string is
KERN: InitVolDesc - volume dataPreparer string is
KERN: InitVolDesc - volume app id string is TOAST ISO 9660 BUILDER COPYRIGHT (C) 1997-2005 SONIC SOLUTIONS - HAVE A NICE DAY
KERN: InitVolDesc - copyright is
KERN: ISO9660: volume->blockSize = 2048
KERN: ISOMount: block size multiplier is 1
KERN: ISO9660: cache init: dev 8, max blocks 315659
KERN: ISO9660 Extensions: Microsoft Joliet Level 1
KERN: InitNode - ENTER, bufstart is 0x8147ca4d, record length is 34 bytes
KERN: InitNode - ext attr length is 0
KERN: InitNode - data start LBN is 200333
KERN: InitNode - data length is 2048
KERN: InitNode - flags are 2
KERN: InitNode - fileUnitSize is 0
KERN: InitNode - interleave gap size = 0
KERN: InitNode - volume seq num is 16777217
KERN: InitNode - file id length is 1
KERN: DirRec ID String is: .
KERN: RR: Start of extensions at 0x8147ca6e
KERN: ISOMount - EXIT, returning 0x85c55510

[pulkomandy]

Duplicate of #11455 which has an analysis of the problem in the ticket comments.