Page MenuHomeFreeBSD

makefs cd9660: Populate creation time stamps in RockRidge extensions
ClosedPublic

Authored by jhb on Jun 10 2026, 2:52 PM.
Tags
None
Referenced Files
F169629063: D57527.id.diff
Wed, Sep 2, 3:00 AM
Unknown Object (File)
Mon, Aug 31, 2:08 PM
Unknown Object (File)
Mon, Aug 31, 8:42 AM
Unknown Object (File)
Mon, Aug 31, 5:51 AM
Unknown Object (File)
Mon, Aug 31, 3:18 AM
Unknown Object (File)
Mon, Aug 31, 3:14 AM
Unknown Object (File)
Mon, Aug 31, 2:53 AM
Unknown Object (File)
Mon, Aug 31, 2:10 AM
Subscribers

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 73805
Build 70688: arc lint + arc unit

Event Timeline

jhb requested review of this revision.Jun 10 2026, 2:52 PM

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).

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.

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?

In D57527#1324036, @jhb 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.

This revision was not accepted when it landed; it landed in state Needs Review.Jun 23 2026, 3:52 PM
This revision was automatically updated to reflect the committed changes.