The message "stat failed %s" seems to say that stat() failed to
do something, or failed to pass a test, but of course it means
that the statting of something failed. So say so. Also make
two very similar messages equal to this one.
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
This adds a concise description of a tool to its usage text.
A first form of this patch was proposed by Steven Honeyman
(see http://www.spinics.net/lists/util-linux-ng/msg09994.html).
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
If current TZ has no representation of a given time_t then localtime()
would return NULL and break the next strftime().
In practice this happens very likely on systems with 64bit time_t when
parsing broken binary data. Seen on aarch64 (and probably s390) using
our (incompatible) test wtmp data.
Signed-off-by: Ruediger Meier <ruediger.meier@ga-group.nl>
(unless bug[s]) This change is backwards compatibile. Earlier binary to
text dumps can be converted back to binary, or otherway around.
The only thing that will not work are IPv6 addresses that possible
earlier conversion had broke. Such conversions resulted with random IPv4
in place of IPv6 address in text format, and original information is gone
forever.
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
In include/bits/utmp.h the ut_user and ut_time macros are marked with
comment they are backwards compatibility hacks. It is probably best to
avoid use of these macros where ever possible.
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
- don't support --follow for stdin at all
- inotify based implementation closes the file, so don't close it in
main() again
Signed-off-by: Karel Zak <kzak@redhat.com>
[utmpdump.c:82]: (style) The function 'unspace' is never used
[utmpdump.c:131]: (style) The scope of the variable 't' can be reduced
[utmpdump.c:167]: (warning) scanf without field width limits can crash with huge input data
[kzak@redhat.com: - don't use scanf field width limits for integers]
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
Signed-off-by: Karel Zak <kzak@redhat.com>