🚀 go-pugleaf

Hello GNU tar person!

I just pulled prep.ai.mit.edu:/pub/gnu/tar-1.11.tar.Z (or something to
that effect) and compiled it up on a couple of different systems
(HP-UX and Linux).  For the most part it compiled up easily and ran
okay.  Good Job!

The pertinent information:

GNU tar 1.11
HP-UX 8.07 HP cc on a 9000/720               \__ Both exhibit same behavior.
Linux 0.97.1 with gcc 2.2.2d on a 386SX-25   /

However, I have been having some difficulty and have found what
appears to be a couple of bugs.  I would like to know, "Do I actually
have the latest version?"  (I don't want to spend too much time
debugging something that has already been fixed.)

There are three problems that I have run into so far.

1. The utime(2) system call seems to be different for these systems
   from what the code was developed for.  This causes compile time
   incompatibilities on these systems.  From the available man pages:
      #include <utime.h>
      int utime(const char *path, const struct utimbuf *times);
   This appears to be true on SunOS 4.1.2, HP-UX 8.07, Linux 0.97.1.
   Unfortunately on your systems it must be an array[2] of time_t
   values instead of this struct.
      int utime(const char *path, const time_t *times);  ???
   This is an easy problem for me to fix.  I would be happy to supply
   the patch for this.

2. The normal mode for me to create tar files is "tar cvf file.tar *".
   The verbose flag 'v' prints the filename as it archives the file.
   This does not work.  Tracking the problem down it appears that the
   variable current_file_name is used to print the name. Unfortunately
   this variable is not set during the create archive operation and so
   happens to be <NULL> on my systems.  The filename is not printed.
   
3. Next is a flakey problem that I don't understand.  Sometimes I get
   the contents of the file echoed to the screen on archive creation.
   I think this is related to the current_file_name not being set as
   described above.  This then happens to print file contents instead
   of the filename because it just happens to point there.  I am not
   convinced of this since in the debugger it never does this.  I
   don't understand it and only mention it because I am seeing the
   problem.

I would be happy to send in patches for these problems if it would
help in any way.  If there is a newer version I would love to get a
copy of it.

Thanks

Bob Proulx
rwp@fc.hp.com