OSDev.org

Hi,

I wrote code that goes through the root directory of a certain CD image, formatted with ISO 9660 level 3, to find a certain file. But I noticed that for some reason if the file it's looking for is past the first 13 files in the directory it won't find it. In other words it stops searching after 13 entries. So, using bochs, I tried to figure out what's wrong. I found that the 14th entry has an entry length of 0. Why is that?

When I mount the image using an image mounter, it displays all the files. How can that be? If the fourteenth entry has an entry length of 0, how can the image mounter read it?

Isaac wrote:...

My newly invented "magic ball" says that you are using an emulator or "remarkably well behaved" PC, and aren't loading enough sectors, and are using blank memory (ie. all zeros).

- Monk

tjmonk15 wrote:My newly invented "magic ball" says that you are using an emulator or "remarkably well behaved" PC, and aren't loading enough sectors, and are using blank memory (ie. all zeros).

Well, your newly invented "magic ball" is wrong. I see data after the field where the entry length should be. Also, considering the ISO 9660 sector length of 2048 bytes it's pretty clear that this is not at a sector boundary.

Isaac wrote:

tjmonk15 wrote:...

Well, your newly invented "magic ball" is wrong. I see data after the field where the entry length should be. Also, considering the ISO 9660 sector length of 2048 bytes it's pretty clear that this is not at a sector boundary.

Since you entirely missed the point of my post...

Clearly you have more information than we do. Maybe if you shared more information we might actually be able to help you.

- Monk

If memory serves, an entry length of 0 indicates a deleted entry that can safely be skipped.

MDenham wrote:If memory serves, an entry length of 0 indicates a deleted entry that can safely be skipped.

Please explain yourself a little more. What do you mean by "If memory serves"?

"If he remembers correctly, an entry length 0 means an entry can be skipped safely."

requimrar wrote:"If he remembers correctly, an entry length 0 means an entry can be skipped safely."

Yes, this. The problem is that I'm going off of what I remember from another project entirely that I haven't been involved with in about six years, so it's entirely possible that I'm wrong as well, but I believe that was the conclusion that the people I was working with and I had reached.

I was wondering what to skip. When the entry length is 0 and I skip 0 bytes because that's the size of the entry, I get nowhere. So I decided to skip 1 byte (i.e. skip the entry length field which reads 0, and move on to what should be the next entry). But for some reason my file is still not found.

Isaac wrote:I was wondering what to skip. When the entry length is 0 and I skip 0 bytes because that's the size of the entry, I get nowhere. So I decided to skip 1 byte (i.e. skip the entry length field which reads 0, and move on to what should be the next entry). But for some reason my file is still not found.

If it's the path table, you'd skip eight bytes (the length of an entry with an empty directory identifier).

For directory entries, I believe you'd skip 34 bytes (again, the length of an entry with an empty name, plus a padding byte to make its length even).

I would strongly recommend loading the CD image in question into a hex editor and looking at what's there "by hand" in conjunction with the wiki page on ISO 9660 just to get a better idea of what might be going on, though. Sometimes that lets you catch things more easily than whack-a-mole style programming.

I opened the image in a hex editor (Bless), and found a strange thing. Some number of entries into the root directory, there is a space between two entries. This space is 8 bytes long and all 8 bytes are zeros. This must be where my code gets stuck. Any explanation for such a strange thing?

Isaac wrote:I opened the image in a hex editor (Bless), and found a strange thing. Some number of entries into the root directory, there is a space between two entries. This space is 8 bytes long and all 8 bytes are zeros. This must be where my code gets stuck. Any explanation for such a strange thing?

I see similarities between this and previous post, look at this part once again:

MDenham wrote:If it's the path table, you'd skip eight bytes (the length of an entry with an empty directory identifier).

Isn't it the information that you're looking for?

My code searches the root directory, not the path table. Also this discovery of an eight byte space between two entries was in the root directory.

Hm. What's the location in the file of that eight-byte gap? I have a suspicion about what might be going on, but I'd like confirmation one way or the other first.

EDIT: Also, does the thirteenth file have a non-zero extended attribute record length?

What do you mean by the "location of the fie of that eight-byte gap"? The eight byte gap is not in a file, it's in the root directory.

MDenham wrote:EDIT: Also, does the thirteenth file have a non-zero extended attribute record length?

I'm sorry. It was my mistake. The code actually gets stuck after the fourteenth entry. It also skips the first two entries (root directory "parent", and root directory) which means that the place it gets stuck at is actually between the sixteenth entry and the seventeenth. This eight-byte gap is also found exactly there (i.e. between entry 16 and 17).

The sixteenth entry has has an extended attribute record length of 0.