Four fixes.

[mingwandroid]

While helping out with gitian deterministic builds I ran into 4 problems.

[wolfcw]

Well, not sure what "disabling cache expiration" actually would mean, but being able to change the libfaketime "configuration" at run-time is an important feature for many use cases; when linking one's own program with libfaketime, changing the FAKETIME env variable is easy and performant; and when using it via LD_PRELOAD with a third party program, changing the content of, e.g., ~/.faketimerc does the trick. On the other hand, no caching at all generally results in poor performance, so -DNO_CACHING should only be used when changes to the "configuration" are made rapidly so the cache timeout really hurts more.

When ft_mode changes cause issues, wouldn't it be possible to "restart" libfaketime with the new settings, or, if that doesn't work, just ignore the change and stick to the old mode/configuration?

[rbalint]

I meant we could add an option (env var) to read ~/.faketimerc only once per process with keeping the current behavior of libfaketime when this new option is not set.
Another potential improvement would be checking mtime to skip parsing the config file again if it has not changed since the last parsing.
With the current small files parsing them again and again is not an issue, but we could also extend the configuration file syntax to set faking rules per command (argv[0]), to fake time only for specific processes in a huge program, like faking it only for javadoc in a build.

[wolfcw]

OK, thanks for this clarification. I agree this would be an interesting idea. :-) Please also look at suan's #12 #13 #14 for related discussion.

Being able to modify the cache timeout at run-time (it's hardcoded atm) would be great; special values like 0 and -1 could disable caching / time-based cache expiration completely.

Checking the mtime seems to be limited to 1 second resolution on many file systems; suan did some testing on this in the above-mentioned issues and resorted to an mmap()-based approach. As any of this comes with some significant performance overhead, it shouldn't be active by default but only when explicitly requested by the user.

Specifying commands / process argv[0]s to which libfaketime applies would also be useful for those who use the system-wide installation method of libfaketime, which currently often gives some issues with, e.g., reboots (forced fsck's) and system updates (too large time differences). Any new configuration options should therefore support some sort of wildcards and have both positive and negative statements (e.g., use only for process x; use for any process but y).

[rbalint]

@mingwandroid There are open questions regarding some of the commits. If you still would like to have them merged please answer them or we close this pull request on 15 February based on lack on interest on you side.

[mingwandroid]

I'll do my best to allocate enough time to look at this before the deadline.

Thanks for the warning.