On Tue, Sep 19, 2006 at 02:26:00PM -0700, Paul Eggert wrote:
> "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.
This may be a kernel bug because I'm used User-Mode-Linux which is not
as stable/accurate as it should be. The problem occurs only in this
environment for me.
--
Raphael Bossek
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
