[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: rollover translator

From: Bas Wijnen
Subject: Re: rollover translator
Date: Mon, 01 Nov 2004 10:38:50 +0100
User-agent: Mozilla Thunderbird 0.8 (X11/20040926)


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.


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]