Since upgrading to GNU tar 1.16, we've been getting "Unexpected field value in snapshot file" errors from our backup scripts on a few of our machines.
After some investigation I found bug 18487 in the Savannah bug tracker, which seems to apply to our situation: http://savannah.gnu.org/bugs/?18487 I searched the web and gnu-tar list archives for any further discussion of this problem but didn't find any (and don't see anything applicable mentioned in the tar 1.18 NEWS file), so I am providing some addition information in hopes that it is helpful. I was able to reproduce the problem on one of the affected machines using a simple test case: # mkdir temp temp/proc temp/testdir # mount -tproc proc temp/proc/ # tar --create --file ~/tar_test.tar --one-file-system \ --listed-incremental ~/tar_incremental.snar temp # tar --create --file ~/tar_test-2.tar --one-file-system \ --listed-incremental ~/tar_incremental.snar temp tar: Unexpected field value in snapshot file tar: Error is not recoverable: exiting now As described in the original bug report, the problem appears to be in the timestamp field for the "proc" entry in the snapshot file. (If I unmount temp/proc, delete the snapshot file, and repeat the tar commands, the second run does not produce any error.) Here is what the snapshot file looks like (as displayed by "less"): # less ~/tar_incremental.snar GNU tar-1.16-2 [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED] [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@temp/[EMAIL PROTECTED]@[EMAIL PROTECTED]@1186159126^@ [EMAIL PROTECTED]@[EMAIL PROTECTED]/[EMAIL PROTECTED]@^@ (Note the "18446744071852258736" value which appears in the temp/proc entry.) I noticed that if I run the "stat" command on the contents of temp, the proc entry's timestamps (the decimal portion of the seconds) look wrong, too: # stat temp/* File: emp/proc' Size: 0 Blocks: 0 IO Block: 1024 directory Device: 3h/3d Inode: 1 Links: 144 Access: (0555/dr-xr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2007-05-01 10:15:14.-1857292880 Modify: 2007-05-01 10:15:14.-1857292880 Change: 2007-05-01 10:15:14.-1857292880 File: emp/testdir' Size: 48 Blocks: 0 IO Block: 131072 directory Device: 902h/2306d Inode: 23900 Links: 2 Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2007-08-03 13:49:54.011572437 -0400 Modify: 2007-08-03 12:38:46.952905198 -0400 Change: 2007-08-03 12:38:46.952905198 -0400 So it would seem that there is something wrong with the "proc" filesystem itself. I'm running linux 2.6.8 (Debian 2.6.8-2-386 2.6.8-16sarge1 package) on this particular machine, but I am not sure if that's (only) trigger for this problem. (We've noticed this problem on two other machines that are also running some version of 2.6.8, but also have machines running 2.6.8 that aren't showing this problem.) However, it seems like even though the timestamp on "proc" isn't correct, tar shouldn't be creating a snapshot file which it then considers to be corrupt when reading it. Could it be updated (either the routines creating the file or those reading it) to handle this situation more gracefully? Let me know if I can provide any further information on this issue. Thanks. Nathan ---------------------------------------------------------------------------- Nathan Stratton Treadway - [EMAIL PROTECTED] - 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
signature.asc
Description: Digital signature
