The mtime menace

chombee <[email protected]>
Newsgroups gmane.comp.web.pyblosxom.user
Message-ID <1192024335.6791.0.camel@apollo>
There's something simple and elegant about the idea of using plain text
files as blog stories, folders as categories, and the mtimes of the
files as the publishing date.

Unfortunately in practise mtimes in *blosxom are a menace though. It's
irritating when you correct a typo in one blog post and it jumps to the
top of your blog. Far worse, though, are the various innocent operations
that can accidentally modify the mtime of *all* posts in your blog and
completely ruin it. I'm not sure exactly which operations change mtimes
and which don't, but things like renaming a folder, moving a folder, or
syncing a datadir between two machines, possibly only when a sync
follows a move or rename, have several times modified the mtimes of
dozens or hundreds of files at once for me.

I was wondering what solutions other people use for mtimes with
pyblosxom? There are a number of plugins aimed at the problem. I'm in
the process of inserting YYYY-MM-DD-hh-mm timestamps into the filenames
of all my entries to completely replace the mtimes of the files by using
the pyfilenametime plugin.

The problem is that I have quite a few entries that don't have these
timestamps in their filenames yet and that have had their mtimes mangled
already. I don't remember exactly when I posted them all. So I'm having
to go through about 200 entries finding all these problem ones and
adding vaguely accurate timestamps to them.

Is there any better way? Anyway to recover the mtimes of a load of files
after some operation touches them all at once?

Thanks



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.