84cf7ce767
currently limited to Ethereal and all the variants of libpcap filetypes only. We might want to add output compression support to the other tools as well (tethereal, mergecap, ...). We might also want to add support for the other filetypes, but this is only possible if the filetype functions doesn't use special output operations like fseek. One bug is still left: if the input and output filetypes while saving are the same, Ethereal currently optimizes this by simply copy the binary file instead of using wiretap (so it will be faster but it will ignore the compress setting). Don't know a good workaround for this, as I don't know a way to find out if the input file is currently compressed or not. One idea might be to use a heuristic on the filesize (compared to the packet size summmary). Another workaround I see is to remove this optimization, which is of course not the way I like to do it ... svn path=/trunk/; revision=15804
35 lines
636 B
Modula-2
35 lines
636 B
Modula-2
EXPORTS
|
|
wtap_buf_ptr
|
|
wtap_close
|
|
wtap_dump
|
|
wtap_dump_can_open
|
|
wtap_dump_can_write_encap
|
|
wtap_dump_can_compress
|
|
wtap_dump_close
|
|
wtap_dump_fdopen
|
|
wtap_dump_flush
|
|
wtap_dump_open
|
|
wtap_encap_short_string
|
|
wtap_encap_string
|
|
wtap_file_encap
|
|
wtap_file_size
|
|
wtap_file_tsprecision
|
|
wtap_file_type
|
|
wtap_file_type_short_string
|
|
wtap_file_type_string
|
|
wtap_get_bytes_dumped
|
|
wtap_set_bytes_dumped
|
|
wtap_open_offline
|
|
wtap_pcap_encap_to_wtap_encap
|
|
wtap_phdr
|
|
wtap_process_pcap_packet
|
|
wtap_pseudoheader
|
|
wtap_read
|
|
wtap_read_so_far
|
|
wtap_seek_read
|
|
wtap_sequential_close
|
|
wtap_short_string_to_encap
|
|
wtap_short_string_to_file_type
|
|
wtap_snapshot_length
|
|
wtap_strerror
|