Hi Ben,
thanks for reporting this. Please be advised that a newer release is
available upstream, which however likely is not related to your issue.
With your calls, you should not use the '-f' parameter. Without '-f',
the timestamp is passed on to date/gdate for parsing, which yields the
Ian,
thanks for the detailed report, which is clearly to confirm.
libfaketime internally relies on strptime() to parse the user-specified
timestamp.
On current macOS, your examples work reasonably well in the following
variation:
$ FAKETIME_FMT="%Y-%m-%d %T %z" ./faketime -f '2018-06-26
So far, this is intentional behavior of the wrapper script.
Use the command line switch -f, then it should work just as you expect:
faketime -f "+10" stat foo
should do.
Hi Daniel, Mike,
thanks for your analysis, which is pretty much complete from my
perspective.
In the functions intercepted by libfaketime, we need to ensure that the
"offending" parameter is indeed non-NULL, and although this may be the
enforced case in the future when everything on the
Charles,
it's hard to comment this profoundly without giving it some serious and
time-consuming debugging first. Anyway, I assume that your problem
persists with both offsets and start-at dates even when
LD_PRELOADing libfaketime directly, i.e., without the faketime wrapper.
In this case,
Daniel,
for further analysis, you may want to search replace any occurrences of
RTLD_NEXT
by
dlopen(/lib/librt.so.1, RTLD_NOW)
in faketime.c ; this is ugly (not only due to the hardcoded path), but
it may avoid issues with RTLD_NEXT going sideways.
Although I don't know why libc6
Daniel, Matthias,
admittedly I haven't been aware of datefudge so far; seems to me like
both mini-tools have been developed independent of each other since
around 2003.
From looking at datefudge 1.14 (is that the most recent version?), I'd
claim that libfaketime currently provides a
7 matches
Mail list logo
