makefs cd9660: Populate creation time stamps in RockRidge extensions

[jhb]

I tested this by building a little ISO and verifying the timestamps (including birthtime) of the files in the ISO matched the existing files used to build the ISO. I even had it wrong initially (I had forgotten to update the relative offsets to TF.timestamp. Arguably if would be more future-proof to follow the model of the kernel parsing code which sets a pointer to TF.timestamp and increments the pointer after encoding each timestamp, but I can't see us ever adding the three remaining timestamps).

[jlduran]

In D57527#1323967, @jhb wrote:

I tested this by building a little ISO and verifying the timestamps (including birthtime) of the files in the ISO matched the existing files used to build the ISO. I even had it wrong initially (I had forgotten to update the relative offsets to TF.timestamp. Arguably if would be more future-proof to follow the model of the kernel parsing code which sets a pointer to TF.timestamp and increments the pointer after encoding each timestamp, but I can't see us ever adding the three remaining timestamps).

Thank you, I'll rekindle a series of makefs updates and test changes (D54585, et al.) to include cd9660 as well. We kind of need these for accurate time-stamping of NanoBSD images.

[jhb]

In D57527#1323972, @jlduran wrote:

In D57527#1323967, @jhb wrote:

I tested this by building a little ISO and verifying the timestamps (including birthtime) of the files in the ISO matched the existing files used to build the ISO. I even had it wrong initially (I had forgotten to update the relative offsets to TF.timestamp. Arguably if would be more future-proof to follow the model of the kernel parsing code which sets a pointer to TF.timestamp and increments the pointer after encoding each timestamp, but I can't see us ever adding the three remaining timestamps).

Thank you, I'll rekindle a series of makefs updates and test changes (D54585, et al.) to include cd9660 as well. We kind of need these for accurate time-stamping of NanoBSD images.

Do you want me to merge this first or wait for your other patch to land?

[jlduran]

In D57527#1324036, @jhb wrote:

In D57527#1323972, @jlduran wrote:

In D57527#1323967, @jhb wrote:

I tested this by building a little ISO and verifying the timestamps (including birthtime) of the files in the ISO matched the existing files used to build the ISO. I even had it wrong initially (I had forgotten to update the relative offsets to TF.timestamp. Arguably if would be more future-proof to follow the model of the kernel parsing code which sets a pointer to TF.timestamp and increments the pointer after encoding each timestamp, but I can't see us ever adding the three remaining timestamps).

Thank you, I'll rekindle a series of makefs updates and test changes (D54585, et al.) to include cd9660 as well. We kind of need these for accurate time-stamping of NanoBSD images.

Do you want me to merge this first or wait for your other patch to land?

I would prefer that these patches land first (if possible), I'll adapt my changes if needed, but probably only after next week.