Guy Harris wrote:
1) they want to do a capture and have multiple smaller files rather
than one big file;
2) they want to have a capture running continuously, waiting for
something to happen, and when they stop it they don't want all the
traffic that was captured since they started the capture, they want the
last N bytes or packets or minutes of captured data (i.e., they know
something will probably happen, they don't know *when* it will happen,
and they want a trace of traffic from shortly before it happened up to
the point when it happened).
So if people say they want more files in the ring buffer, the first
question I'm tempted to ask is "do you want a ring buffer, or do you
just want Ethereal to keep writing to *new* files as it fills up the old
ones?" If the answer is the latter, then the right fix might be to have
a mode that does that - said mode doesn't keep files open (which I
presume was done as an optimization in the ring buffer code), so it's
not limited by the maximum number of open files.
I currently use 2) but in a way that make me think that keeping the files
open is not so good : I use the "ring buffer switch duration" feature I have
added to be able to have a file per day, i.e. after 24 hours, the switch to
next file is performed whatever its size is. The next step is to compress,
copy the file on tape or another filesystem for archiving.
If the file was not keep open, instead of copying it, it could be simply moved or
deleted after the archiving ... in order to free some more disk space.
When I checked in the "ring buffer switch duration", I said :
Log:
Implement a ring buffer switch duration:
when the new "Rotate capture file every n second(s)" checkbox or the
-b <# of file>[:<duration>] argument are used, [t]ethereal will skip to the
next ring buffer file if the specified duration has elapsed (even if the
specified capture size is not reached). This is useful when you want to have
separate capture files per hour or day for instance.
I let the autostop filesize parameter mandatory (i.e. the "rotate capture
file after n kilobytes") but this could be no longer strictly necessary when
that new feature is used ...
Any comment here ?
Another point: it might be interesting to really truncate the file at the
switch and not the closure ... According to user comments and my own real
case tests, I might plan to enhance this point and others (still ring buffer
related) in the future.
so it might be the time to implement the following at the switch :
- close the previous one
- open the next one (and truncate it if not empty)
with a maximum number of files either increased (64 hardcoded or set in preferences) or
unlimited like Guy suggested ...
According to your remarks, I will implement this.
Laurent