[tpm] more problems than solutions this week
Alex Mackinnon
alexmac131 at hotmail.com
Fri May 4 10:47:03 PDT 2012
Have you considered log4perl? Alex
From: fulko.hew at gmail.com
Date: Fri, 4 May 2012 13:45:12 -0400
To: toronto-pm at pm.org
Subject: [tpm] more problems than solutions this week
Here's the next problem...
How can you tell if a file pointer has been rewound?
The task:
...Follow the contents of a file (and process any new data)
The problem:
While testing the various permutations of how a file (log files)
can get updated you have typical actions like:
- append new data onto the end (new stuff)
- delete the file and start over (after log file rotation)
So one of my test modes was to use shell redirection to
write to a file. ie. echo "stuff" > file
What I thought/expected would happen is that shell would create
a new copy of the file and write the string into it.
[So when my app detects that the inode changed, it would
start reading the new file from the beginning.]
But what I've found is that the inode doesn't change!
[so I'd assume that the ">" redirection simply rewinds
the write pointer to offset zero and writes the string
and then truncates the file at that point.]
So how can I detect that?
One solution I considered was: to remember what the size of
the file was (the last time I looked) and if the new size
is smaller... it must have been truncated using this
technique. That might work for the majority of occurrances,
but it doesn't work with the simplest test.
echo `date` > file results in a 28 octet long file so I'll
remember that it was 28 bytes long for later
...
echo `date` > file the inode hasn't changed and neither has
the file size, yet there was 'new stuff
that needs processing, that I won't see.
...
Suggestions?
(Or do I just throw up my hands in disgust and say I can't/don't
handle that condition?)
Fulko
_______________________________________________
toronto-pm mailing list
toronto-pm at pm.org
http://mail.pm.org/mailman/listinfo/toronto-pm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/toronto-pm/attachments/20120504/a3c086c1/attachment.html>
More information about the toronto-pm
mailing list