search

ratt-ru / purr

Data reduction logging tool, Useful for remembering reductions
GNU General Public License v2.0
1 stars 1 forks source link

Already archived files picked up again upon restart of Purr #24

Closed gijzelaerr closed 10 years ago

gijzelaerr commented 10 years ago
at 2010-07-13 15:59:09 Oleg Smirnov reported:

Already archived files picked up again upon restart of Purr

gijzelaerr commented 10 years ago

Original comment thread migrated from bugzilla

at 2010-07-13 15:59:09 Oleg Smirnov replied:

So far this only affects Debian lenny (8.10 packages), but I'd like to get to the root of this problem as it's VERY annoying.

  1. Start purr, make a new purrlog
  2. touch foo.tmp
  3. Add new entry, foo.tmp is in the list. Make the new entry.
  4. Look at Add new entry again. foo.tmp is not in the list, and shouldn't be until foo.tmp is modified again.
  5. Restart purr.
  6. Look at Add new entry -- foo.tmp is picked up. Shouldn't be.
at 2010-07-26 15:32:38 Oleg Smirnov replied:

Got it, the mystery is why it works right in the first place on most platforms. It all boils down to a float mtime:

purr(Purrer.py:120:isUpdated): WatchedFile /home/oms/Waterhole/contrib/OMS/QMC2/Jul21/batch_cal.sh is updated: mtime 1279968354.779170 07/24/2010 12:45:54 PM, old mtime 1279968354.000000 07/24/2010 12:45:54 PM

Because the timestamp gets converted to an int when written to a purrlog, if the filesystem reports a fractional timestamp, the file will always appear to be newer! Perhaps this is filesystem-dependent? xfs reports fractional timestamps.

I have implemented a fix on birch (basically, keep all timestamps as floats now), will test this and commit later.

at 2010-08-05 21:23:35 Oleg Smirnov replied:

Fixed in r 7836.