Skip Menu |

Date: Mon, 01 Apr 2024 15:55:15 -0400
Subject: profile write operation interactions with reloading
The profile library stores parsed files in prf_data_t objects.  Before each query to a prf_data_t object, the library checks (at most once per second) if the backing file's timestamp has changed.  If so, the parsed relation tree is discarded and the file is reread.  This reloading is suppressed for files marked NO_RELOAD (meaning the backing file is not a regular file), but not for files marked DIRTY due to a previous read/write setup.  Therefore, any write operation could be discarded in favor of new data from the backing file.

If the modification is being done to programmatically modify the backing file, this behavior can be written off as the profile library not having ACID semantics.  But if the modifications are intended for profile_flush_to_file(), or krb5_init_context_profile() if profile_copy() is ever made to work with dirty profiles, then this behavior is unfriendly.
Subject: git commit

Do not reload a modified profile data object

The profile library normally attempts to reload a profile data tree if
the backing file has changed. Reloading a dirty profile object
discards any modifications made by the caller. If we assume that the
modifications are destined to be flushed back out to the backing file,
then there is no good answer--one or the other set of changes will be
lost. But the caller may have a different intended use for the
modified tree (profile_flush_to_file(), profile_flush_to_buffer(),
krb5_init_context_profile()), for which the caller's modifications may
be critical. Avoid discarding in-memory edits to ensure the
correctness of these use cases.
Author: Greg Hudson <>
Commit: 9b2fb80ad24006784170875709a04dc79e03b401
Branch: master
src/util/profile/prof_file.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)