In the POSIX world, files typically possess three fundamental timestamps:
| Timestamp | Alias | Description |
| Access | atime | Access timestamp of the last read. |
| Change | ctime | Status change timestamp of the last update to the file’s metadata. |
| Modify | mtime | Modification timestamp of the last write. |
These timestamps can be easily viewed from a variety of file system tools and utilities. For example, in this case running ‘stat’ from the OneFS CLI:
# stat -x tstr File: "tstr" Size: 0 FileType: Regular File Mode: (0600/-rw-------) Uid: ( 0/ root) Gid: ( 0/ wheel) Device: 18446744073709551611,18446744072690335895 Inode: 5103485107 Links: 1 Access: Mon Sep 11 23:12:47 2023 Modify: Mon Sep 11 23:12:47 2023 Change: Mon Sep 11 23:12:47 2023
A typical instance of a change, or ‘ctime’, timestamp update occurs when a file’s access permissions are altered. Since modifying the permissions doesn’t physically open the file (ie. access the file’s data), its ‘atime’ field is not updated. Similarly, since no modification is made to the file’s contents the ‘mtime’ also remains unchanged. However, the file’s metadata has been changed, and the ctime field is used to record this event. As such, the ‘ctime’ stamp allows a workflow such as a backup application to know to make a fresh copy of the file, including its updated permission values. Similarly, a file rename is another operation that modifies its ‘ctime’ entry without affecting the other timestamps.
Certain other file systems also include a fourth timestamp: namely the ‘birthtime’ of when the file was created. Birthtime (by definition) should never change. It’s also an attribute which organizations and their storage administrators may or may not care about.
Within the Windows file system realm, this ‘birthtime’ timestamp, is affectionally known as ‘create date’. This create date of a file is essentially the date and time when its inode is ‘born’. Note that this is not a recognized POSIX attribute, like ctime or mtime, rather it is something that was introduced as part of Windows compatibility requirements. And, because it’s a birthtime, linking operations do not necessarily affect it unless a new inode is not created.
As shown below, this create, or birth, date can differ from a file’s modified or accessed dates because the creation date is when that file’s inode version originated. So, for instance, if a file is copied, the new file’s create date will be set to the current time since it has a new inode. This can be seen in the following example where a file is copied from a flash drive mounted on a Windows client’s file system under drive ‘E:’, to a cluster’s SMB share mounted at drive ‘Z:’.
The ‘Date created’ date above is ahead in time of both the ‘accessed’ and ‘modified’, because the latter two were merely inherited from the source file, whereas the create date was set when the copy was made.
The corresponding ‘date’, ‘stat’, and ‘isi get’ CLI output from the cluster confirms this:
In before OneFS 9.5, when a file is replicated, its create date is timestamped when that file was copied from the source cluster. This means when the replication job ran, or, more specifically, when the individual job worker thread got around to processing that specific file.
By way of contrast, OneFS 9.5 now ensures that SyncIQ fully replicates the full array of metadata, preserving all values, including that of the birth time / create date.
The primary consideration for the new create date functionality is that it requires both source and target clusters in a replication set to be running OneFS 9.5 or later.
If either the source or the target is running pre-9.5 code, this time field retains its old behavior of being set to the time of replication (actual file creation) rather than the correct value associated with the source file.
In OneFS 9.5, create date timestamping works exactly the same way as SyncIQ replication of other metadata (such as ‘mtime’, etc), occurring automatically as part of every file replication. Plus, no additional configuration is necessary beyond upgrading both clusters to OneFS 9.5.
One other significant thing to note about this feature is that SyncIQ is changelist-based, using OneFS snapshots under the hood for its checkpointing and delta comparisons.. This means that, if a replication relationship has been configured prior to OneFS 9.5 upgrade, the source cluster will have valid birthtime data, but the target’s birthtime data will reflect the local creation time of the files it’s copied.
Note that, upon upgrading both sides to OneFS 9.5 and running a SyncIQ job, nothing will change. This is because SyncIQ will perform its snapshot comparison, determine that no changes were made to the dataset, and so will not perform any replication work. However, if a source file is ‘touched’ so that it’s mtime is changed (or any other action performed that will cause a copy-on-write, or CoW) that will cause the file to show up in the snapshot diff and therefore be replicated. As part of replicating that file, the correct birth time will be written on the target.
Note that a full replication (re)sync does not get triggered as a result of upgrading a replication cluster pair to OneFS 9.5 or later and thereby enabling this functionality. Instead, any create date timestamp resolution happens opportunistically and in the background as files gets touched or modified – and thereby replicated. Be aware that ‘touching’ a file does change its modification time, in addition to updating the create date, which may be undesirable.