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
_______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-hurd
