OK, here's what I see in the 'strace' output, repeated 15 thousand-some-odd times:
write(1, "nfo\nc0121610 t __constant_c_and_"..., 10240) = -1 EPIPE (Broken pipe) --- SIGPIPE (Broken pipe) @ 0 (0) --- So for some reason gtar is ignoring the SIGPIPE signal. There's probably something else going wrong in Amanda, which is causing it to close the pipe into which tar is writing. You can probably find out whats going on by looking at the 'sendbackup' debug logs on the client, and I expect that if you fix the Amanda-side problem, you won't see any more trouble from GNU tar. The question is, why isn't tar doing the right thing when this happens? I tested my local copy of tar like this: $ strace -f tar -cf - . 2>/tmp/trace | true; tail /tmp/trace mmap(NULL, 821, PROT_READ, MAP_SHARED, 3, 0) = 0x2af4a8ffb000 lseek(3, 821, SEEK_SET) = 821 munmap(0x2af4a8ffb000, 821) = 0 close(3) = 0 lstat("./ABOUT-NLS", {st_mode=S_IFREG|0644, st_size=38475, ...}) = 0 open("./ABOUT-NLS", O_RDONLY) = 3 read(3, "Notes on the Free Translation Pr"..., 9216) = 9216 write(1, "./\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 10240) = -1 EPIPE (Broken pipe) --- SIGPIPE (Broken pipe) @ 0 (0) --- +++ killed by SIGPIPE +++ I'm running tar 1.19, and also tested this against 1.15 and 1.13.25, and saw similar (that is, correct) behavior everywhere. What version of tar are you running? Dustin