From: Bob McConnell > From: Uri Guttman
>>>>>>> "BM" == Bob McConnell <r...@cbord.com> writes: >> >> BM> Looking at the two tar files with a binary viewer after uncompressing >> BM> them through gzip, I see several differences, but other than the >> BM> obvious, I don't know which are significant. The obvious difference is >> BM> that the tar file headers for 3.17 all have absolute paths for each >> BM> file. The 3.21 headers do not. The 3.21 headers also contain more fields >> BM> and some are padded differently, but I don't know what effect this would >> BM> have. >> >> the absolute vs relative paths may mean something. maybe the author >> switched tars when they switched source control? tar is best with >> relative paths so you can untar it anywhere. > > I should have said full paths, instead of relative. The difference > is 'prove' vs 'Test-Harness-3.17/bin/prove'. > >> one idea is to untar the file on a linux box and then transfer over that >> tree (using tar again or scp or some other tool like zip). > > CPAN won't let me substitute files. In the first place, the checksum > would no longer work. > >> and this is getting way beyond a beginner's problem. i would take this >> to some other forums like perlmonks or usenet. also have you written to >> the author of the module about this? if it fails for you on winblows, >> then it might fail elsewhere. also try this on another winblows box >> which can help isolate whatever is different about yours. > > I have posted the question on the Camelbox forum, but have not yet > received any response. I don't know where to take CPAN problems, > since I have never had any before. After reading what I can find > of the tar format, I think the utility used to build that tarball > is broken. Each file header should have a full path from the base directory. After a little more digging, and trying your suggestion to try from Linux, I have determined that the directory information in the new tar files is being put into the prefix field of the header. But apparently the older versions of tar (and WinZIP) don't expect anything in that field until the name field is completely full. I haven't seen anything that suggests that doing this should be a standard practice. One of the Camelbox developers did give me a workaround that seems to get me past this issue for now. Thank you, Bob McConnell -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
