While atime synchronization is enabled, you can use either the atime attribute or the retention.txt metafile to trigger synchronization for an individual existing object (for which synchronization is not currently in effect):
- To use the atime attribute to trigger synchronization for an object with retention currently set to a specific date and time in the future, use CIFS or NFS to make a valid change to the value of the atime attribute.
- To use the atime attribute to trigger synchronization for an object with retention currently set to either Deletion Allowed or Initial Unspecified:
To use the retention.txt metafile to trigger atime synchronization for any object, regardless of its current retention setting, change the retention setting for the object to any valid value except a retention class.
Important:
- Some commands you can use to store objects in the namespace, such as the Unix cp command, have options for preserving the original permissions and timestamps. These commands may modify permissions and atime values in a way that causes the stored object to become read-only, thereby triggering retention. If atime synchronization is enabled, you should review the use of these commands to ensure they do not result in unexpected retention settings.
- Existing applications ported to HCP may remove write permissions from objects without regard to their atime values. If atime synchronization is enabled for the namespace, this can have the unintended effect of giving some objects infinite retention. Be sure to review ported applications for this behavior before running them.
Triggering atime synchronization for an object creates an association between its atime value and retention setting. Subsequent changes to POSIX permissions do not remove this association.