VOGONS

Search

Common searches

Unable to use valid ISO image because of isoDirEntry size

Topic actions

First post, by hakonrk

Posted on 
User metadata
Rank Newbie
Rank
Newbie

I have a valid (by which I mean that Linux and Windows fs drivers have no problem with it) ISO image whose directory entries are not being read because of this statement in drive_iso.cpp:

if (data[0] > sizeof(isoDirEntry)) return -1;

In my particular case, data[0] is 136 and sizeof(isoDirEntry) is 133, so DOSBox just gives up.

I have looked at Linux' iso_directory_record, and like DOSBox' version, it has 33 bytes before the directory entry name. Unlike DOSBox' version, Linux doesn't limit the file name array to 100 bytes, instead allowing whatever is specified in the name_len byte (i.e., up to 255 bytes for the file name, which is permitted with the Rock Ridge extension).

I have no idea why my ISO file has directory entries that exceed 133 bytes, as all filenames in the image conform to the 8+3 FAT standard, but for now, I have changed the ident[100] array to ident[256] in src/dos/drivers.h's isoDirEntry struct. Is there a reason for the (seemingly arbitrary) limit of 100 bytes?

Reply 1 of 5, by prompt

Posted on 
User metadata
Rank Newbie
Rank
Newbie

In the first version of the iso handling code the directory entries were cached, so I put the arbitary 100 there to save some memory, but in the meantime this changed, so nothing speaks against using some higher value there, if it is needed. (If I counted correctly this makes 222 bytes for the identifier).

Reply 2 of 5, by hakonrk

Posted on 
User metadata
Rank Newbie
Rank
Newbie
prompt wrote:

In the first version of the iso handling code the directory entries were cached, so I put the arbitary 100 there to save some memory, but in the meantime this changed, so nothing speaks against using some higher value there, if it is needed. (If I counted correctly this makes 222 bytes for the identifier).

OK, so you're changing the array size from 100 to 256 in CVS then? (Assuming that the name_len parameter does not include the terminating zero byte, 256 is the smallest possible value that's guaranteed to be big enough for any directory entry.)

Reply 3 of 5, by prompt

Posted on 
User metadata
Rank Newbie
Rank
Newbie

I do not have access to the cvs, but may be one of the dosbox devs is listening?

(Btw 222 bytes for the identifier is still the only value that makes sense to me since the maximal size of a directory entry is 255 bytes and the other fields sum up to 33 bytes. In Rock Ridge, a file name bigger than that is stored in the extension.)

Reply 4 of 5, by hakonrk

Posted on 
User metadata
Rank Newbie
Rank
Newbie
prompt wrote:

(Btw 222 bytes for the identifier is still the only value that makes sense to me since the maximal size of a directory entry is 255 bytes and the other fields sum up to 33 bytes. In Rock Ridge, a file name bigger than that is stored in the extension.)

You're right, of course. I forgot that the total size in bytes of the entire record is also described in eight bits.

Go to top of page Go to top of page
Back to DOSBox Development
Close window
Close window