Alfred M. Szmidt wrote:
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.
What I meant was that we can disregard POSIX aslong as programs
reading/writting from the file work as expected. And as far
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.
What I meant was that we can disregard POSIX aslong as programs
reading/writting from the file work as expected. And as far as I can
tell, POSIX d
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
Not sure if this is what Alfred had in mind, but that's how I got it.
Thing is, I only know of the behaviour from the program that I would
like to see. I haven't thought about the exact implementation
details.
Maybe I should just whip up something and see... But first I have to
fix this darn
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
Hi Ognyan,
Today at 10:06, Ognyan Kulev wrote:
> POSIX read/write can't work as expected when filesystem changes file
> pointer at fs's own will.
I don't think there's a need to change file pointer at all. It's only
up to the translator to treat any file pointer into (100MB+something)
as pointe
it, it's perfectly legal (in POSIX) someone
else to truncate file that is processed by another user. So concerning
POSIX, this rollover translator that truncates file from time to time is
OK. But I still think that in the general case noone except owner of
file descriptor can change fd
If program uses POSIX API, then there should be POSIX behaviour.
Meh, I was unclear. What I meant was that the translator can do
whatever it wants to the file offset. Aslong as read/write/whatever
work as expected.
One way to circumvent this is by declaring that this is socket, not
fi
Alfred M. Szmidt wrote:
I'm not sure if POSIX allows filesystem (by its own will) to change
file offset of user file descriptor.
We don't have to care about POSIX here.
If program uses POSIX API, then there should be POSIX behaviour. In
POSIX, each file descriptor has file pointer/offset/wh
BTW, isn't it good to have logrotate[1] translator?
Sure, but not as part of the rollover translator. logrotate might be
made part of a versioning translator, since they behave in a similar
manner. The only difference is that you don't save the old content
when you start a n
Ognyan Kulev wrote:
Another possible implementation is to use sparse blocks: keeping
everything before the last X bytes to be sparse blocks. So file will be
huge, but only the part we are interested in is saved physically. But I
think we don't have RPC that make sparse blocks inside file, not
I'm not sure if POSIX allows filesystem (by its own will) to change
file offset of user file descriptor.
We don't have to care about POSIX here.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-hurd
Alfred M. Szmidt wrote:
I got this funky idea today, but I'm not sure what would be the best
way to implement it. What it would essentially do is provide a
"circular file", so when you get to the end of the file you start from
position 0. With the nice option that if you do roll over, you can
cle
Unfortunatly, I'm having trouble thinking off an easy way to do the
what I want, i.e. I want to specify a translator the way you say
above an always have the last 100M of log messages. So, the point
of my incorherence is that instead of the file rolling over, I just
want the file to
Alfred M. Szmidt wrote:
If program uses POSIX API, then there should be POSIX behaviour.
Meh, I was unclear. What I meant was that the translator can do
whatever it wants to the file offset. Aslong as read/write/whatever
work as expected.
One way to circumvent this is by declaring that this
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
>> Hey,
> >
> > I got this funky idea today, but I'm not sure what would be the best
> > way to implement it. What it would essentially do is provide a
> > "circular file", so when you get to the end of the file you start from
> > position 0. Wit
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
> Hey,
>
> I got this funky idea today, but I'm not sure what would be the best
> way to implement it. What it would essentially do is provide a
> "circular file", so when you get to the end of the file you start from
> position 0. With the nice o
Hey,
I got this funky idea today, but I'm not sure what would be the best
way to implement it. What it would essentially do is provide a
"circular file", so when you get to the end of the file you start from
position 0. With the nice option that if you do roll over, you can
clear the all stored
18 matches
Mail list logo
