Skip to main content

UNIX: ssh + tar + gzip -q = goodness

To retrieve a hierarchy of files from a remote server (or to copy it back to a remote server), I often do something like:
ssh servername "tar cvzf - dirname" | tar xvfz -
However, I usually get the following error message:
gzip: stdin: decompression OK, trailing garbage ignored
tar: Child returned status 2
tar: Error exit delayed from previous errors
Strangely enough, as I write this, I get the error message copying something from one FreeBSD system to another FreeBSD system, but I don't get it when copying something from one FreeBSD system to my Ubuntu system. Weird.

I put up with this problem for years. However, I recently needed to use it in a Makefile. Having an error like that is fine when you're a human, but a non-zero return code is a deal-breaker in a Makefile. I needed to clean up my act.

One easy way to make the problem go away is to not use the "z" flag for both instances of tar. This is somewhat icky, because it really would be nice to have the content gzipped. Otherwise, it could take too long to transfer.

Finally, I found the real solution on the gzip Web site. Instead of passing the "z" flag to tar when untarring, use gunzip separately and pass the "q" flag to tell it to be quiet:
ssh server "tar cvzf - dirname" | gunzip -q | tar xvf -
By the way, as is standard in UNIX, there are plenty of other variations of this tar + ssh idiom. For instance, consider:
ssh server "cd myapplication/share/locale && 
find . -name '*.po' -o -name '*.mo' |
xargs tar cvzf -" |
gunzip -q | tar xvf -


Anonymous said…
From Brandon Golm:

do you have anything agains cpio, and letting ssh handle the compression
with '-C' ??

well... your way is good too.
jjinux said…
I can never remember the arguments for cpio ;)

I didn't know about ssh's "-C" argument. That's *even better* (less typing!), although I sure am glad to know the right way to work around my other way.
jjinux said…
ssh -C servername "tar cvf - dirname" | tar xvf -

Yep, worked just fine!
Leon Atkinson said…
I wonder if compression is all that relevant, anyway. Most of the time, I have a fast, unsaturated network between my local machine and any remote machine.
Leon Atkinson said…
OK--I couldn't resist testing. It's relevant for my 768K DSL connection. My crude test showed 1 minute versus 6 minutes.

I wonder if I shouldn't add "Compression yes" to /etc/ssh/ssh_config.
Anonymous said…
Take a look at rsync. :)
Anonymous said…
I don't find cpio all that difficult:
cpio -i means data is coming from stdin,
cpio -o means data is going to stdout.

find directory (-some-complicated-query) | cpio -o
find directory (-some-complicated-query) -print0 | cpio -0o
is easier than
find directory (-some-complicated-query) | xargs -d'\n' tar cf -
find directory (-some-complicated-query) -print0 | xargs -0 tar cf -
(for safety with working with filenames with spaces and other interesting characters)
jjinux said…
> I don't find cpio all that difficult:

+1 for usefulness. I stand corrected!
Unknown said…
your problem here was that you had the "v" option on the sending side of the tar, instead of just on the untar.
ssh user@host "tar czf - dirname " | tar zxvf -
should work fine.
jjinux said…
> your problem here was that you had the "v" option on the sending side of the tar, instead of just on the untar.

Wow, that makes perfect sense! Thanks!

Popular posts from this blog

Ubuntu 20.04 on a 2015 15" MacBook Pro

I decided to give Ubuntu 20.04 a try on my 2015 15" MacBook Pro. I didn't actually install it; I just live booted from a USB thumb drive which was enough to try out everything I wanted. In summary, it's not perfect, and issues with my camera would prevent me from switching, but given the right hardware, I think it's a really viable option. The first thing I wanted to try was what would happen if I plugged in a non-HiDPI screen given that my laptop has a HiDPI screen. Without sub-pixel scaling, whatever scale rate I picked for one screen would apply to the other. However, once I turned on sub-pixel scaling, I was able to pick different scale rates for the internal and external displays. That looked ok. I tried plugging in and unplugging multiple times, and it didn't crash. I doubt it'd work with my Thunderbolt display at work, but it worked fine for my HDMI displays at home. I even plugged it into my TV, and it stuck to the 100% scaling I picked for the othe

ERNOS: Erlang Networked Operating System

I've been reading Dreaming in Code lately, and I really like it. If you're not a dreamer, you may safely skip the rest of this post ;) In Chapter 10, "Engineers and Artists", Alan Kay, John Backus, and Jaron Lanier really got me thinking. I've also been thinking a lot about Minix 3 , Erlang , and the original Lisp machine . The ideas are beginning to synthesize into something cohesive--more than just the sum of their parts. Now, I'm sure that many of these ideas have already been envisioned within , LLVM , Microsoft's Singularity project, or in some other place that I haven't managed to discover or fully read, but I'm going to blog them anyway. Rather than wax philosophical, let me just dump out some ideas: Start with Minix 3. It's a new microkernel, and it's meant for real use, unlike the original Minix. "This new OS is extremely small, with the part that runs in kernel mode under 4000 lines of executable code.&quo

Haskell or Erlang?

I've coded in both Erlang and Haskell. Erlang is practical, efficient, and useful. It's got a wonderful niche in the distributed world, and it has some real success stories such as CouchDB and Haskell is elegant and beautiful. It's been successful in various programming language competitions. I have some experience in both, but I'm thinking it's time to really commit to learning one of them on a professional level. They both have good books out now, and it's probably time I read one of those books cover to cover. My question is which? Back in 2000, Perl had established a real niche for systems administration, CGI, and text processing. The syntax wasn't exactly beautiful (unless you're into that sort of thing), but it was popular and mature. Python hadn't really become popular, nor did it really have a strong niche (at least as far as I could see). I went with Python because of its elegance, but since then, I've coded both p