On Friday 05 of February 2010 17:54:02 Andreas Dilger wrote:
> I would argue that any nanosecond value >= 10^9 is simply due to
> corruption, and propagating that into the seconds field isn't really
> helping anything. However, I agree that it should also check for ns <
To be frank, I've no real life test-case showing it's helpful.
> It is probably worthwhile to have e2fsck et. al. check for and fix
> such corruption, but there are already filesystems in the wild with
> these bad timestamps and tar shouldn't segfault when backing them up.
My reproducer was based on RHEL-5 implementation of tmpfs and I am not
aware of anything like fsck.tmpfs :-)
Attached is a new version of the patch.
Kamil
diff --git a/src/misc.c b/src/misc.c
index 951449e..49738a2 100644
--- a/src/misc.c
+++ b/src/misc.c
@@ -257,6 +257,10 @@ code_timespec (struct timespec t, char sbuf[TIMESPEC_STRSIZE_BOUND])
char *np;
bool negative = s < 0;
+ /* ignore invalid values of ns */
+ if (BILLION <= ns || ns < 0)
+ ns = 0;
+
if (negative && ns != 0)
{
s++;
