Sergey Poznyakoff <[EMAIL PROTECTED]> wrote: > Hi Jim, > >> - in --create mode, with a named target (i.e., not stdout), >> - with stderr closed, and >> - in a way that provokes tar to write a diagnostic, >> then tar corrupts the named output archive by writing the diagnostic it. > > Thanks for reporting that. However I agree with Jörg that this is not a > tar problem, and that a better fix would be to ensure in main that > descriptors 0, 1, 2 be open.
Hi Sergey, I've had the same reflex. If you feel you must do that, then consider lib/stdopen.c from coreutils cvs. It is good enough in the vast majority of cases: http://savannah.gnu.org/cgi-bin/viewcvs/coreutils/coreutils/lib/stdopen.c?rev=HEAD&content-type=text/vnd.viewcvs-markup BTW, it is not sufficient to ensure that they are open. To be 100% faithful (in failing when any application tries to access initially-closed file descriptors) an implementation must ensure that *no* syscall operates successfully on the reopened file descriptors. But afaik, that is not possible. Hence, my preference to leave them closed. _______________________________________________ Bug-tar mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-tar
