"Raphael Bossek" <[EMAIL PROTECTED]> writes:
> --- tar-1.15.91.orig/src/extract.c
> +++ tar-1.15.91/src/extract.c
> @@ -918,7 +918,7 @@
> for (; ds; ds = ds->next)
> if (ds->dev == st1.st_dev
> && ds->ino == st1.st_ino
> - && timespec_cmp (ds->mtime, get_stat_mtime (&st1)) == 0)
> + && tar_timespec_cmp (ds->mtime, get_stat_mtime (&st1)) == 0)
> {
> struct string_list *p = xmalloc (offsetof (struct
> string_list, string)
> + strlen (file_name) + 1);
That sort of patch doesn't look correct to me, as it is comparing two
time stamps both gotten by 'stat' or 'lstat'. They should be
consistent, even if the underlying file system does not have
full timestamp resolution.
Possibly your kernel temporarily remembers subsecond time stamp
resolution, so long as the inode is cached, but forgets it once it's
sent to disk? That might explain the problem. But that would be a
kernel bug, not a tar bug.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
