Re: [tcpdump] New feature to limit capture file size (#464)

[Wesley Shields <wxs () FreeBSD org>]

> On Jun 10, 2015, at 7:35 AM, Darren Reed <darrenr () 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.

-- WXS
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers