Can not read filesystem in ISO9660 image with creation timestamp about go-diskfs HOT 6 OPEN

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.

from go-diskfs.

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.

from go-diskfs.

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.

from go-diskfs.

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.

from go-diskfs.

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.

from go-diskfs.

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.

from go-diskfs.