Can not read filesystem in ISO9660 image with creation timestamp

[schwarzlichtbezirk]

When I create ISO-image with UltraISO program with any data and any image size, and set image creation (or/and modification) timestamp, this image can not be opened with this API. This image is well opened in Windows explorer, but cannot be read by API. Call to GetFilesystem(0) returns error "Unknown filesystem on partition 0". Creation timestamp can be set in UltraISO image properties in tab date/time. If timestamp is not set, it's all working.

ISO-image is opens with subsequent calls:

	if disk, err = diskfs.OpenWithMode(fpath, diskfs.ReadOnly); err != nil {
		return
	}
	if fs, err = disk.GetFilesystem(0); err != nil { // assuming it is the whole disk, so partition = 0
		return
	}

[deitch]

If you upload an image that fails to be read to somewhere it can be downloaded, we can look at it. I think there are size limits on GitHub issue attachments, but not sure.

[schwarzlichtbezirk]

example.zip

I put example ISO-image into zip-archive. There is 3 short text files nested into image for example. When I create this image, I set only creation filestamp and nothing any more.

[deitch]

The creation timestamp on this image appears to be corrupt. The ISO primary volume descriptor date is supposed to be in byte positions 813-829, as follows:

• year: bytes 0-3
• month: bytes 4-5
• date: bytes 6-7
• hour: bytes 8-9
• minute: bytes 10-11
• second: bytes 12-13
• centisecond: bytes 14-15
• offset from UTC: byte 16 (in quarter hours)

All of the above look fine, except for centisecond.

2021 04 20 15 47 16 \x000

They all are ASCII codes for characters, except for the bytes at 14-15, which are: [0,48]. 0 is a null character, nit a valid number. The ASCII code for the character 0 is 48.

It is possible I misunderstood the spec on that specific part - centiseconds - so checking it again.

[deitch]

Nope, it is pretty clear that the hundredths of a second are in the format strD here, or if you prefer, check the official ECMA spec, it is on page 28.

[schwarzlichtbezirk]

I looked in the hex editor image with all timestamp fields set, in all timestamps hundredths of a second is not set, and it's looks like zero-terminated string. Standard does not specify behavior if hundredths of a second is not set (or case when date is set, but time is not set). What is optimal resolution can be for this case I do not know, but I think that broken timestamp can not be a valid reason for image open failure. Those images are produced by popular UltraISO prorgam, so such cases can occurs very often.

[deitch]

I am pretty confident that UltraISO is incorrect. If this is 0, it should be 0x48 0x48, and not 0x00 0x00. Either way, it definitely is not a null-terminated string.

That having been said, there is no reason why this library couldn't handle those deviant cases, by checking if the hundredths of second is 0x00 and treating either of the fields as 0x48.

Go ahead and open a Pull Request for it.