Closed deitch closed 3 months ago
In my app, I get the following error:
2024/05/22 17:13:53 error copying file boot/limine-bios-cd.bin to disk, copied 20480 bytes, expected 20480
panic: error copying file boot/limine-bios-cd.bin to disk, copied 20480 bytes, expected 20536
Which is triggered by this check. If I disable it, then it completes and the produced .iso boots up!
Note the invalid value for the expected one in the error message.
In my app, I get the following error: Which is triggered by this check.
That check should make sense. With every file, we expect it to copy either the file size, or file size plus boot table size, if we added it.
How can we replicate your issue?
Let me put itt up somewhere. Playing around with which files I included or changing the name of the one failing, does pass in some cases.
That helped.
Here is what I do not remember, as it has been years since I did the iso9660 implementation.
When a record has a boot table, i.e.:
ElTorito: &iso9660.ElTorito{
BootCatalog: "boot.cat",
Entries: []*iso9660.ElToritoEntry{
{
Platform: iso9660.BIOS,
Emulation: iso9660.NoEmulation,
BootFile: "/boot/limine-bios-cd.bin",
BootTable: true,
LoadSize: 4,
},
{
Platform: iso9660.EFI,
Emulation: iso9660.NoEmulation,
BootFile: "/boot/limine-uefi-cd.bin",
BootTable: true,
},
},
},
BootTable
is set to true
.
In that case, it generates the boot table and inserts it into the file from offset 8 for 56 bytes.
Is that supposed to override the data in the file at those bytes, keeping the file the same size? Or insert it into the file at that location, thus extending the file by 56 bytes?
The code from years ago implies that it overwrites it, which is why your sample is failing, as the test later assumes that it is inserted.
So I am going to put back the original test, just allowing for the case that the original file is <56 bytes.
Try it now.
Success! Very nice and your prompt support very much appreciated!!
The rock ridge extensions at various places assumed all files were actual files in the workspace. However,
finalizeFileInfo
supports in-memory files.The solution is to extend
finalizeFileInfo
to have the additional features rock ridge is looking for: accessTime, modTime, linkTarget.finalizeFileInfo
already implementsfs.FileInfo
. Then we can convert the call to RockRidge to just acceptfinalizeFileInfo
and get the properties.My tests show it works.
Fixes #215