??????????

Bumping this again, as I still need this.

I implemented your changes in my fork now:
LTRData@ca3b9c3

I plan to publish new NuGet packages with this fix soon. Thanks a lot for your contribution!

Could you take a look at this test case? It fails after this modification. I am not sure whether the test was actually wrong previously, or if anything is wrong now.
https://github.com/LTRData/DiscUtils/blob/ca3b9c38e615d3eb3a24ead202ee230a39af28c7/Tests/LibraryTests/Iso9660/BuilderTest.cs#L52

Not really sure, but we were writing the boot sectors wrong in the first place, it’s likely that the test had similarly wrong parameters.

Okay, sounds like it makes sense. I'll try to figure out how this could be tested in some other way.

Okay, fixed the test case and built new nuget packages. Packages from my fork are prefixed with LTRData., so for example LTRData.DiscUtils.Iso9660. Note also that there are some breaking changes because that fork has evolved a bit in last few years since it was forked from this repo.

.net 8 targets as well for nuget? =)

.net 8 targets as well for nuget? =)

Yes!

excellent. KAPE is getting ported to your library for v2

I went back and actually checked; The test was correctly failing and I'm not calculating the boot sectors correctly for hard disk emulation. @LTRData I would advise reverting the test change and committing the suggestion above.

Thanks! But I guess we also need to fix FixExtents method as well, where it sets _bootEntry.SectorCount = 1 for all other BootMediaType values than NoEmulation? Should it set it to actual number of sectors for HardDisk type boot images as well, or should it be calculated from some kind of boot record like for floppy images?

Uggggh, I think see the issue. I had thought that I was calculating the sector count wrong because the test was reporting 512, but the test assumed the boot IMAGE was first because it used to write IMAGE, then CATALOG (this does not conform to the El Torito spec, it's supposed to be CATALOG then IMAGE). So the test read the boot catalog size, which is always 1 sector, 512 bytes.

So, to sum up, I think you have the tests fixed correctly and you don’t have to change anything. I will investigate with real world examples to make sure.

Having looked more into this, I think that there is some logic missing i SetBootImage for harddisk emulation. We would need something corresponding to what mkisofs does here:
https://github.com/Distrotech/cdrtools/blob/8adb0d06e070464f13d017b1de7187bf23dacd87/mkisofs/eltorito.c#L374

Also, OpenBootImage would need some similar logic to find actual image size. We cannot use size of the boot entry for hard disk emulation either, because it is always 1. But we also cannot calculate the size in a way similar to how it is done for floppies because there really is no geometry data like that in the MBR for hard disks. I think I'll look more into this before doing more changes.