[Laurent Deniel <laurent.deniel@xxxxxxx>]

> > Right, and this is exactly what I want in some cases (i.e. *one* file 
> > which
> > is limited in size). But not so important than the "unlimited" case.
> Again, what is the *use* of only one ring buffer file? What is it 
> helpful for?
>
> You cannot use it with the "Update list of packets in realtime" option, 
> so it won't be helpful to have something like an unlimited "display 
> only" capture.

With the current ethereal code no, but see below.

> And if you stop capturing at the "right" moment, your file will be 
> empty, so you won't get any valuable data from the capture.
>
> That's exactly the trap I wanted to avoid for first time users, 

You can simply put '2' as the default value to avoid '1' for the
first time users ;-)

> as I didn't saw a use case for a single ring buffer file.

My use case is the following: [t]ethereal captures the data and writes
into a single file which has a max size [ring buffer with 1 file].
Another program reads it and decodes it on the fly: no need to cope with
changing (and opening at the right time!) files which names changes,
but only to be able to seek correctly (or reopening) when the file is
truncated (I don't care if some packets are badly decoded at the truncation).
I have a more sophisticated approach with pipes and an ugly patched
(so not yet integrated if ever) ethereal which does the realtime decoding
as well.

I don't care if you let the GUI as is if I still can do the same approach
by command line (-b 1).

Laurent