[tpm] more problems than solutions this week

[Indy Singh]

Wouldn’t the timestamp of the file have changed?

For this case you could also do a checksum or crc of the file.  If the file is huge it may be enough to crc just the first few kilobytes of the file.

Indy Singh
IndigoSTAR Software -- www.indigostar.com

From: Fulko Hew 
Sent: Friday, May 04, 2012 1:45 PM
To: TPM 
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/d9d1320f/attachment-0001.html>