>When using -atime -ctime (to let star restore all inode times after the >dump), star with root privs undeterminably fast-forwards the system time.
>This is really SERIOUS bug, which should not occur in such software. >This is probably caused by the method of restoring i-node ctime, see >star/star_unix.c:654: There is no such serious bug in star, but if you really have this problem, you would need to file a bug report against your kernel which seems to be Linux..... This feature has been introduced about 20 years ago and tested intensively. There never have been bug reports related to this feature. Star meters the time needed for the operation and restores the old time with a correction for the time needed for the operation. This is not 100% correct and there is a tendency for a system time _lag_ of approx. 1ms per extracted file. If you have the opposite effect or if the effect is much bigger, you obviously did hit a bug in the kernel. To be more precise: When I extract the archive opensolaris-src-20050720.tar.bz2 which contains approx. 35,000 files, the system clock delays by 150 seconds during the whole star run. >Possibly (another) bug: Doesn't sole "curtime.tv_usec += pasttime.tv_usec;" >statement ignore possible pasttime.tv_sec change for cases, when the >intermediate part lasted unexpectedly long? This indeed is a small bug, but it is only present in case you extract POSIX.1-2001 enhanced TAR archives that include time stams in nanosec granularity. It has been fixed today. Check ftp://ftp.berlios.de/pub/star/alpha/star-1.5a65pre.tar.bz2 Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED] (uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -.-
