jclark.org/weblog

Party like it’s 1969

One the first plugins I decided to use for this weblog was wikieditish, a fantastic plugin by Rael Dornfest, author of Blosxom. This plugin allows the posting and editing of blog entrys via a web page. Among its features are password protection and modification date preservation.

Date preservation is important, because Blosxom uses a story’s file-system modification time as the posting time of the story. However, when I started using it, new posts created by wikieditish all had a date of Dec 31, 1969 at 16:00. A search of the Blosxom mailing list found a description of the problem, but not the solution.

Eventually, I worked it out. The problem is caused when $preserve_lastmodified is set. In the following code, the comment says something the code does not:

 # If file already exists, memorize the lastmodified date/time
  my $mtime = (stat "$blosxom::datadir$path/$fn.$file_extension")[9];

There is no If in the code – when the file does not exist, the stat call returns no value. So when $mtime is used later, its numeric value is 0:

 # reset lastmodified date/time to memorized value (if possible)
     $preserve_lastmodified
       and utime(time, $mtime, "$blosxom::datadir$path/$fn.$file_extension")
         ? $response .= " Preserved last modified date/time."
         : warn "blosxom : wikieditish plugin : couldn't reset lastmodified 
           time on $blosxom::datadir$path/$fn.$file_extension.";

utime expects a date/time value as seconds since the epoch. The epoch is Jan 1, 1970, 00:00 GMT. Those of us west of GMT see this as a time during the evening of Dec 31, 1969. In my case, 16:00, which is 8 hours prior to midnight, which tells me my host in on Pacific time.

My fix for this is brief. In the above code, we don’t proceed if $mtime is 0:

 # reset lastmodified date/time to memorized value (if possible)
     $preserve_lastmodified
       and $mtime
       and utime(time, $mtime, "$blosxom::datadir$path/$fn.$file_extension")
       ? $response .= " Preserved last modified date/time."
       : warn "blosxom : wikieditish plugin : couldn't 
         reset lastmodified time on
$blosxom::datadir$path/$fn.$file_extension.";

Its possible some people don’t have this problem with the code as written. Judging from the code, I think perhaps utime is expected to fail with a 0 arg. Since utime is just a wrapper for utime(2) on most systems, this could be a difference between *nix implementations… but that’s all theory :) The code fix however is actually tested.

Both comments and pings are currently closed.