Well, at this point I bow out. I only have the vaguest notion on this question, and none at all yet regarding how tar and the b/gzip compression algorithms interact. It's also not a question that casuses an itch with me. However, my vague notion on the garbage bytes you report at the end of the archive must have to do, it seems, with how the various apps recognize and act on eof messages. In particular, I suspect there'd be no facility to roll back if a receiving process gets the data a little late, since that might be far mor complex and dangerous than simply tolerating a few extraneous bytes on the tail. Might it be these represent empty encrypted tcp packets? Luke Davis writes: > Okay. Debian provides a pretty good man page for rmt, which, Greg, is in > fact the program used for this purpose, according to the info pages on > tar. > > It uses a reasonably simple protocol, which PERL could emulate enough to > make this work, but I don't think that will be necessary. > > Because, the following syntax works nicely, exactly as is: > > tar --rsh-command=ssh --bzip2 -cf user at host:path/to/file.tbz files > > The only problem this seems to have, and I get the same thing with the ssh > pipe, is that bzip2 seems to find garbage after EOF, in any bzip2 archive > created with this method. Anyone have any idea what that is? > > All kinds of diffing, against the original and the backup, the backup and > another backup done with a different method, and more, turns up no > differences between the backed up directories, so it doesn't seem to > matter much; but I still don't like it. > > Luke > > _______________________________________________ > Speakup mailing list > Speakup at braille.uwo.ca > http://speech.braille.uwo.ca/mailman/listinfo/speakup -- Janina Sajka, Chair Accessibility Workgroup Free Standards Group (FSG) janina at freestandards.org Phone: +1 202.494.7040
