Re: [Bug-tar] Issue with GNU Tar and HP-UX LVM v2.2 filesystems

[Nathan Stratton Treadway]

On Mon, Dec 10, 2012 at 11:32:04 +0100, Joerg Schilling wrote:
> > Specifically, when tar is writing the snapshot file, in the
> > write_directory_file_entry() function in incremen.c, it writes the
> > device number using:
> >
> >       s = umaxtostr (directory->device_number, buf);
> >       fwrite (s, strlen (s) + 1, 1, fp);
> >
> > -- but in your case dev_t is signed, and when device_number turns out to
> > be negative, using umaxtostr on it doesn't produce the expected
> > output.
> >
> > The write_directory_file_entry function does check to see if time_t is
> > signed and act accordingly, so maybe something similar could be done for
> > dev_t, but in that case it looks like the read_incr_db_2 would also need
> > to be updated to handle a signed "dev" field....
> 
> What do you call "expected"?

Well in this case the point is only that GNU tar aborts with an error
message when it goes to read back in that particular field from the
snapshot file...
 
> dev_t is an unsigned number but POSIX says, it is signed.
> 
> At least for the classical header part, the correct treament for TAR is to
> ignore the POSIX signedness and to archive/fetch unsigneds.

Interesting.  

I think this would still require some fixes for both writing and reading
the snapshot file (on systems with signed dev_t), but it might be easier
than actually writing a negative value to the file.

Hopefully Paul or Sergey will have an idea of the best way forward.

                                                Nathan

----------------------------------------------------------------------------
Nathan Stratton Treadway  -  address@hidden  -  Mid-Atlantic region
Ray Ontko & Co.  -  Software consulting services  -   http://www.ontko.com/
 GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt   ID: 1023D/ECFB6239
 Key fingerprint = 6AD8 485E 20B9 5C71 231C  0C32 15F3 ADCD ECFB 6239