[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.

(Or do I just throw up my hands in disgust and say I can't/don't
handle that condition?)


toronto-pm mailing list
toronto-pm at pm.org
-------------- 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