[tcpdump-workers] [tcpdump] New feature to limit capture file size (#464)
wxs at FreeBSD.org
Wed Jun 10 11:02:31 EDT 2015
> On Jun 10, 2015, at 7:35 AM, Darren Reed <darrenr at netbsd.org> wrote:
> On 10/06/2015 5:42 AM, Michael Richardson wrote:
>> re: https://github.com/the-tcpdump-group/tcpdump/pull/464 Guy writes:
>>> We have the -C option, giving a file size in megabytes (real megabytes, i.e. 1,000,000 bytes, not 1,048,576 bytes); once the file gets that big, tcpdump switches to a new file. This adds another file size option, with a different syntax for the size option, and with tcpdump stopping rather than rotating files when it reaches that size. We also have the -G option, to rotate files based on time rather than size. We might want to consider cleaning up these options a bit, so that we can specify "stop" vs. "rotate" and "file size" rather than "capture time" independently.
>> thoughts? I'm happy to accept the patch once sane, and then clean it up as Guy suggests.
> Maybe it is time to work out how this should interact now...
> Why is there even a need to have -G and -C?
> Aren't both really just the same feature? (file rotation)
> But with a different parameter?
> Why can't it be "-C 1h,500M"? (rotate after 500M or 1h)
> ... and so on.
> I think the "We might want to..." paragraph is right but that more thought
> is needed.
Whatever the decision is can we be sure that the various options (-G, -C and -W) are kept for backwards compatibility for a long time? I ask because I know of some places which are using -G to write packets in time sliced files and changing the semantics of that flag would cause mass chaos.
What has never been clear to me is how -G, -C and -W work together, so any way to simplify things there and make it clearer is welcome by me.
More information about the tcpdump-workers