Append packets to already written pcap file(tshark)

*No, it's not possible to append to a capture file *

This answer isn't entirely true. There is at least one other way to append the packets from one capture file to another capture file. Assuming you have a pcap file and not a pcapng file, you can use this method to append file2.pcap to file1.pcap:

tail -c +25 file2.pcap >> file1.pcap

This command causes tail to write all bytes of file2.pcap to the end of file1.pcap ... except for the first 24 bytes, which is the libpcap global header. Since file1.pcap already has a global header, these bytes must be skipped.

NOTE: The resulting merged file will have a single global header which will apply not only to the packets that were contained in the original file1.pcap prior to appending file2.pcap's packets, but to the appended packets as well, which may not necessarily make sense for those packets, depending upon how those packets were captured and on what system.

See Libpcap File Format for more details on the libpcap global header.

This method can't be used quite as easily (and likely not at all in every case) with pcapng files though because for one thing, the Section Header Block (SHB) is not a fixed length, but if you happen to know the size of the SHB, then in theory this could still be achieved with at least some pcapng files as well. After peaking at a pcapng file's SHB using hexdump, I was able to successfully merge two pcapng files this way once I learned the value of the SHB's Block Total Length. I wouldn't go so far as to say that this method would work with all pcapng files though.

DISCLAIMER: Don't mistake me mentioning this method as my endorsement of it. I think it's far safer, better and easier to simply use mergecap, but it is possible to append packets to a file using at least one alternate method, as I've shown.

You can use View -> Reload as File Format/Capture to switch the view from the "normal" packet view to a file view showing the blocks. The option is a toggle between the view modes.

I think we can agree on that you cannot resume a running capture after it was stopped - merging, byte copy concatenation etc. is always possible of course. So I think the answer is still true if you keep in mind that it was about continuing a previous stopped capture writing new live packets to avoid having to manually concatenate files.

Well, that's true. You can't resume a running capture after it has been stopped without losing the already captured packets; however, you can continue to pipe multiple capture files to a continuously capturing instance of Wireshark using the tail method described above. I don't know when or if this would ever be useful to someone, but for what it's worth, here's how you could do it, at least on Linux (and possibly on other unix's too, but I have only tested this on Linux):

Create a fifo, which Wireshark will capture from, but ensure Wireshark never receives EOF (that's the sole purpose of the cat command): mkfifo sharkfin wireshark -k -i sharkfin & cat > sharkfin &

Have Wireshark read the first pcap file, including the libpcap global header: cat file_1.pcap > sharkfin

Continue to have Wireshark read any number of other pcap files (hopefully they all match the libpcap global header of the first file): tail -c +25 file_i.pcap > sharkfin

I don't know how you would accomplish this on Windows, but I'll leave that as an exercise for the reader. :)

Agreed. And it's a nice example of thinking outside the box on your side:-)