[Bug-tar] Timestamps in ././@LongLink entries

[Adam Greenblatt]

Hi,
   In tar-1.14, in create.c, the function "start_private_header" sets the
mtime field of private blocks, such as "././@LongLink" entries, to be the
current time.  This means that successive invokations of tar on an  
unchanging
directory tree can produce different tar files; a real nuisance when trying
to use, e.g., the md5sum of a tarball to determine its correctness.  Here's
a patch that will leave the mtime field of these private blocks set to all
nulls, which seems harmless enough: it passes "make check", anyway.  You  
might
instead wish to set the mtime to match the mtime of some other entry in the
tarfile; that's fine, as long as tarring up the same directory tree yields
deterministic results.
   My apologies if you've already fixed this behaviour in the latest  
sources,
I haven't had a chance to look at the cvs tree...   Thanks for all your
effort!
   Adam Greenblatt (address@hidden)

diff -Naur tar-1.14/src/create.c tar-1.14-orig/src/create.c
--- tar-1.14/src/create.c       2004-10-03 13:55:41.000000000 -1000
+++ tar-1.14-orig/src/create.c  2004-04-25 23:17:20.000000000 -1000
@@ -374,6 +374,7 @@
 union block *
 start_private_header (const char *name, size_t size)
 {
+  time_t t;
   union block *header = find_next_block ();

   memset (header->buffer, 0, sizeof (union block));
@@ -381,6 +382,8 @@
   tar_copy_str (header->header.name, name, NAME_FIELD_SIZE);
   OFF_TO_CHARS (size, header->header.size);

+  time (&t);
+  TIME_TO_CHARS (t, header->header.mtime);
   MODE_TO_CHARS (S_IFREG|S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH,  
header->header.mode);
   UID_TO_CHARS (getuid (), header->header.uid);
   GID_TO_CHARS (getgid (), header->header.gid);