UDF (no iso) images contain extra 2KB of data on end

[rbeede]

InfraRecorder version 0.46.2

I create a simple UDF (no iso) image with just one text file on it. I write it to an iso image on my hard disk.

I try opening the UDF iso file with the 7-zip utility. It cannot read the UDF iso, but other udf iso made in other program can be read. The developer of 7-zip (http://www.7-zip.org/) stated:

There is problem with that archive. It contains additional 2 KB at the end
of archive.
Can you ask developers of InfraRecorder about these 2 KB?


What would the extra 2KB be?

[kindahl]

The InfraRecorder UDF implementation has been verified against multiple tools in order to verify its correctness. I am not aware of any additional 2 KB data, but I will try this out my self when I have time.

[rbeede]

I'm following this issue in the 7-zip bug tracker as well. https://sourceforge.net/tracker/?func=d ... tid=114481

The iso would appear to pass spec verification tools. The question is why does the tool/spec have an extra 2KB of data at the end of the image?

Is this something that the ckFileSystem just does? Information on why the spec allows/needs this will help in the implementation of 7-zip, a tool that can extract files from iso images.

[kindahl]

I don't remember the specification details by memory, but I can't recall that any 2 kB should be appended at the end. However, padding in general is very common in the ISO/UDF specification. If a file is 3 bytes large it will be padded with 2045 bytes of zeros.

Yes, the ISO/UDF creation is the workings of ckFileSystem (which I have also implemented). I haven't had time to analyze the disc image yet, but I will look into it at soon as possible.

[rbeede]

Have you had a chance to look at the disc image yet? Is there anything I can do to help?

[rbeede]

Any particular references or specifications I could read about this?

[rbeede]

Had any chance to look into this?

[kindahl]

Sorry for the delay... I have looked into this and confirmed that InfraRecorder pads an extra sector for UDF images. I have changed this behavior for the 0.47 release. I have validated that the disc images created with that version opens in 7-zip.

Regarding if its legal or illegal with the extra padding is a tricky question. The UDF and ISO9600 standards does not define a file system structure for use in file dumps at all. One could imagine dumping all sectors of a disc and thus have lots of padded sectors. It's really ipavlov's call if he wants to search the disc image backwards in order to find the descriptor or simply assume that it exist in the last block (as currently). I would expect most disc authoring software not to have any unnecessary blank sectors after the last real one.

[rbeede]

Thank you for your attention to this. It will be most helpful in working with images.

I wish UDF and other filesystems were more clear. Writing a spec is okay, but I have trouble following them. I have been researching UDF though. Ideally there wouldn't be so many formats and new formats would be developed at a level that a college level freshman C.S. student could be taught it. That's an ideal world though.