Re: rollover translator

[Bas Wijnen]

Hi,

A rollover translator sounds like a nice idea :-)

Danilo Segan wrote:
> Today at 9:09, Alfred M. Szmidt wrote:
>
>
> > I like this idea too, for real log files this has more sense.  But I
> > am not sure at all how one would go about to implement.
> >
> > When one writes N bytes to the file when at the end of the file, one
> > would somehow have to remove the N top bytes, and push all contents up
> > N bytes and then start writting those N bytes.  And this would have to
> > be done all the time when writting.

I think the idea of sparse blocks is to add one block at a time to the 
end, and clear and remove one block at a time from the "start".  This 
should be possible with sparse storage as far as I understand it (which 
isn't very far, by the way ;-) ).  The idea is simply that the blocks 
from the start aren't removed, they are just not stored, because they 
are (made) empty.

A disadvantage of this idea is that you could not go on infinitely with 
this, as you will hit a file size limit at some point.

> Ok, I don't know exactly what translators can and cannot do, so this
> may be shooting in the dark.
>
> But, how about write()s doing an operation "remainder of division" on
> file pointer, and read()s simply starting with some point in a log
> file (where writing itself would start).

I thought of this as well, and think it should be possible.

> This will bring in some strange behaviour (i.e. read()'s might
> sometimes return latest data instead of earliest),

I would say read() will move the read file pointer to the nearest 
available data if it's below that.  It starts at zero, so at the first 
read it will move to the position of the write pointer (plus an 
arbitrary number of loops).  If there is too much write() before the 
next read(), it will simply skip over the lost data (which is now new 
data) and return the next.  It might even notify the reader by inserting 
some code in the data stream, but I don't think that's a good idea, as 
that code in the data stream would have to be escaped, which is just ugly.

> but provided we
> assume tail(1) is what's used to generally read the files, it should
> be doable.  Or not?

I think so.

About the POSIX-discussion:
I don't think we care about POSIX at all here.  If Alfred wants to write 
a translator which is totally non-POSIX, he should be free to do so.  It 
may even be included in the Hurd, if it seems useful for certain 
applications.  Of course the programs using it will be Hurd-specific and 
non-POSIX as well, but it is up to the programmer to care about that.  I 
think we should advise people not to use such a translator in any "real" 
application, as it would be better if that would be portable, but I 
think the translator would be very useful for debugging tools.  It does 
things which simply cannot be done on other systems.

Thanks,
Bas

signature.asc
Description: OpenPGP digital signature