Nathan Stratton Treadway <[email protected]> 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:[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/private/ ftp://ftp.berlios.de/pub/schily
