[Bug 748452] System registry cache file

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=748452

--- Comment #7 from Dan Nicholson <nicholson at endlessm.com> ---
For some background, what we're doing is deploying a system with OSTree
(https://wiki.gnome.org/Projects/OSTree). This is essentially a read only
system, so unless the user has added their own plugins to their home directory,
a registry file created and shipped with the OS should be sufficient for all
users.

One issue which prevents this is the hashing of the environment variables
discussed above. Another issue is the use of st_ctime when hashing plugin
dependencies -
http://cgit.freedesktop.org/gstreamer/gstreamer/tree/gst/gstplugin.c#n1485. We
can control the modification times (st_mtime) so that they stay persistent
between composing and deploying the OS, but there's no way to control the
ctime.

However, I don't think that the ctime is significantly beneficial here. From
stat(2) (http://man7.org/linux/man-pages/man2/stat.2.html):

       The field st_mtime is changed by file modifications, for example, by
       mknod(2), truncate(2), utime(2), and write(2) (of more than zero
       bytes).  Moreover, st_mtime of a directory is changed by the creation
       or deletion of files in that directory.  The st_mtime field is not
       changed for changes in owner, group, hard link count, or mode.

       The field st_ctime is changed by writing or by setting inode
       information (i.e., owner, group, link count, mode, etc.).

Everything you really care about is covered by an mtime updates. I suppose the
ctime is a convenient way to see if the owner/group/mode changed, but I would
argue that hard link count should not affect the registry. It also doesn't
capture if the owner/group/mode actually changed from before; it could have
been changed and changed back. Assuming owner/group/mode are important (I'm not
sure they are), I suggest using st_uid/st_gid/st_mode directly instead of using
st_ctime.

Thoughts?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.