Hmmm - you may have something in the behaviour of gtar. Using: cat /dev/zero | gtar -tf - gives:
GTAR ORIGIN VERSION RESULT ------------------------------ ------- ----------------- /usr/sfw/bin/gtar Sol10 U8 1.17 runs forever /usr/sfw/bin/gtar Sol10 U8+patches 1.22 exits immediately /opt/csw/bin/gtar Sol10 opencsw 1.23 exits immediately But, if I use the gtar '--ignore-zeros' flag (exists in 1.17 as well as 1.22/1.23) then all versions keep running forever. We're compiling (and running) amcheckdump on a machine with gtar version 1.22, so perhaps that's the issue? Did gtar's default behaviour with respect to zeroes between 1.17 and 1.22? Since we're using amgtar to validate, I tried adding: property "COMMAND-OPTIONS" "--ignore-zeros" to our amgtar application definition, but this didn't make any difference. From the amgtar log file, the gtar command that was invoked was: Sat Aug 7 08:09:09 2010: amgtar: Executing: /usr/sfw/bin/gtar '-tf' '-' So I've either done something wrong, or amcheckdump doesn't use the amgtar definition to do the validation. I'm on vacation for a week, but I have a colleage that monitors this list and can respond if there's anything else you'd like us to test. Thanks for your help with this, Sean > >On Thu, Aug 5, 2010 at 2:57 PM, Sean Walmsley ><s...@fpp.nuclearsafetysolutions.com> wrote: >> It looks to me like: >> >> Â - process 10344 (amcheckdump) creates a pipe >> Â Â with file descriptors 8 and 9 at each end. >> Â - the process forks off a child (10350) >> Â - the parent closes fd8 >> Â - the child closes fd9 and eventually dups >> Â Â fd8 onto fd0 (std in) > >Nice work! You'll also notice this absolutely brain-dead behavior by >good 'ol Perl: > >10350: dup(8) = 9 >10350: fcntl(8, F_GETFD, 0x082320DC) = 1 >10350: dup(8) = 11 >10350: llseek(8, 0, SEEK_CUR) Err#29 ESPIPE >10350: close(8) = 0 >10350: fcntl(11, F_DUP2FD, 0x00000008) = 8 >10350: close(11) = 0 >10350: fcntl(9, F_DUP2FD, 0x00000008) = 8 >10350: fcntl(8, F_SETFD, 0x00000001) = 0 >10350: close(9) = 0 > >which is the long way 'round the barn to accomplish, well, nothing >really. However, you'll note that it is thread-unsafe! In >particular, if some other thread happens to open a new file descriptor >8 between close(8) and dup2(11, 8), then that thread's file descriptor >will get clobbered. This behavior is only invoked when running on >Sun's libc (Solaris and, I've learned, Nexenta), but sadly it's going >to force us to reimplement the entire perlio layer. Anyway, enough >ranting for now. That's not actually causing the problem here as far >as I can tell. > >> Eventually, (line 4461) the child seems to exit normally with >> exit status of 0. It looks to me like this is an orderly >> exit with normal cleanup, closing of file descriptors, etc. > >This is an accurate description, and I don't see anything in the truss >output that you missed. I just don't know why tar quits! It hasn't >gotten *any* indication that it is nearing EOF, not even a short read: > 10350: read(0, 0x080AA000, 10240) = 10240 >To my knowledge, GNU tar will not exit before it gets EOF. In fact, >we depend on GNU tar to happily digest a lot of trailing zeroes on >dumpfiles, since some devices (tapes) pad the end of a file with >zeroes. > >What does > cat /dev/zero | /usr/sfw/bin/gtar -tf - >do for you? On my Solaris 10 system, it runs forever, and a truss >shows tar reading 0's in 10k increments without any output. I even >tried concatenating zeroes onto a real tarfile, with the same result: > (tar -cf - test; cat /dev/zero) | /usr/sfw/bin/gtar -tf - > >I'll check on the GNU Tar list, but let me know what you find. > >Dustin > >-- >Open Source Storage Engineer >http://www.zmanda.com
