The tar format has to know the size of the entry before it can write the header that goes before the data.
With your proposal, there's no way for tar to know the size of the data without actually reading all of the data. To work around this, tar would have to copy the data to a temporary file itself. So you wouldn't really gain anything over using a temporary file. In some cases, you might have a programmatic way to determine the size in advance. If this is true for your application, you might consider writing a custom archiving program based on the libarchive library, which was designed to make it very easy to create tar archives with dynamically-generated content. (If you cannot determine the size in advance, libarchive now has support for writing zip format, which does not require knowing the size in advance.) http://libarchive.googlecode.com/ has full details, including example code. Cheers, Tim Kientzle Alexander T wrote:
Hi, This is my first message to this list, so hi everyone and I hope that this is the right place to post. I would like to submit a feature request: to add a flag for including the contents of FIFO:s, like --dereference, but for named pipes. The problem this would solve is tar:ing multiple large program outputs without using intermediate files, something like mkdir bck mkfifo bck/1.dump mkfifo bck/2.dump dbdump db1 > bck/1.dump & dbdump db2 > bck/2.dump & tar -c?f bck.tar bck It is currently of course possible to come up with some workarounds, but they have drawbacks and this would IMHO be a very nice addition. There are some google results with people having the same problems: http://www.unix.com/unix-advanced-expert-users/30365-tar-fifos.html , http://stackoverflow.com/questions/2021873/linux-adding-named-files-to-a-zip-archive-from-a-pipe/2022012#2022012 and http://www.linuxquestions.org/questions/programming-9/make-tarziprar-play-nice-with-named-pipes-593392/ Best Regards, Alexander T
