bug-tar
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Joerg Schilling
Subject: Re: [Bug-tar] Issue with GNU Tar and HP-UX LVM v2.2 filesystems
Date: Mon, 10 Dec 2012 11:32:04 +0100
User-agent: nail 11.22 3/20/05

Nathan Stratton Treadway <address@hidden> wrote:

> > cghbck a 2.2 vg
> > 
> > -2147475455            dev_t      st_dev       ID of device containing file
>
> I ran into a similar problem a few years ago, and though in my case it
> was the "nsec" value that was negative (due to a kernel bug), it looks
> like the same thing is happening here.  
>
> 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"?

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.


Jörg

-- 
 EMail:address@hidden (home) Jörg Schilling D-13353 Berlin
       address@hidden                (uni)  
       address@hidden (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily



reply via email to

[Prev in Thread] Current Thread [Next in Thread]