Sergey Poznyakoff <[email protected]> writes: >> In some cases just the error message is a bit misleading. > > What message are you referring to?
Sorry, it was mostly the Solaris one that says "filename is greater than 100" for just about anything ;) The GNU TAR error messages are fine. Sure "max 256" is not 100% accurate, but I would not know what message should work better, "maybe" path name exceeds the USTAR format limitations; not dumped The "cannot be split" means nothing to the normal user, but I can't find a better message there either, unless repeating the same message as above about USTAR format limitations. But too general error messages makes debugging harder. But not important, sorry for mentioning it. >> The third line (1) triggers the bug again, making second header to >> have nothing in the "name" field. > > Yes, indeed. Thanks for reporting. > >> Worse, in the test (1) the third record is corrupt, "name" is >> "cccc....bbbb...." with no "/", i.e. file name is wrong. > > Can't reproduce this. In this case I get 100 'c' characters in the > name field and the correct prefix. Can you send me the tar archive > you got in this step? Sorry, sloppy weekend coding from my side. The debug snippet I wrote to debug this didn't take into account that in some situations, no \n is added by strncpy(). So the "Worse..." part above is not correct. Ah, I tried without your patch now an can't reproduce the problem if the directory is 100-154 characters and the file 100, works fine. So guess the patch needs some more work ;) Thank you Sergey and thank you Tim for taking the time to answers to my questions! kent -- Kent Boortz, Senior Production Engineer Sun Microsystems Inc., the MySQL team Office: +46 863 11 363 Mobile: +46 70 279 11 71
