Re: The mtime menace

Just to get more specific, I thought I would post my analysis of the
various plugins for getting round the mtimes problem, just to see if
I've missed anything or if anyone has any other solutions.

The pyfilenametime plugin uses timestamps in the filenames of the files.
At first I liked this because it has the advantage that if you list your
files in alphanumeric order it will also happen to be their order in
your blog, so that's handy when editing your datadir. Additionally, you
can have files in your blog that don't have timestamps in their
filenames, and pyblosxom will just use their mtimes instead. So you can
get the old behaviour if you want on a per-file basis.

I realised though that it's easy to list files in order of mtime in any
file browser, so the first advantage doesn't count. And it has some
disadvantages. It becomes irritating to type the filenames if you're
editing on the command line, and if you want to change the date of an
entry then you have to change the filename, so it's permalink changes.

Alternatively there is the rdate utility which I haven't tried, but it
says it stores the original mtime of each post in a metadata tag inside
the file and has a utility to reset the mtime of a file to the one
stored in this tag. This sounds pretty good. In a file browser or on the
command line you could list files in order of mtime, the names of your
files would not be mangled with ugly timestamps, and you could edit the
metadata tag in a file to change it's date without changing the filename
and breaking the permalink. If your mtimes get messed up, just run rdate
over all your files and it will modify all of the mtimes to match the
timestamps stored inside the files. If it comes across a file with no
time tag it creates the initial tag with with the mtime value of the
file. So as long as you remember to run rdate regularly enough you
should be protected from any operation destroying all your mtimes.

Lastly there are a number of plugins - hardcodedates, entrycache and
rememberdates, which cache all of your original mtimes in one file. I
don't like the sounds of that, as that file becomes a single point of
failure, it may get very huge and become a performance bottleneck, and
it would be awkward to edit.

So it seems to me that rdates is the best approach. I could write a
script to convert all the timestamps I currently have in filenames to
metadata tags for rdates and remove them from the filenames, then I'd
have to manually add tags for any other files whose mtimes are
incorrect. After that rdates should do a nice job of removing the mtime
menace.

Any thoughts?

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/