file timestamps and removal [was Re: SPUG:DOS / BASIC Script]

Michael R. Wolf MichaelRunningWolf at
Sat Jan 18 17:44:49 CST 2003

Doug Beaver <doug at> writes:

> On Fri, Jan 17, 2003 at 04:07:19PM -0800, Michael R. Wolf wrote:
> >
> > I've done a similar thing, using Unix dates (useful for scripts) and
> > also human readable dates encoded in the filename.
> > 
> > How 'bout something like this (no warranty, completly untested..):
> > 
> > # Name, create, use, close, and touch(1) a log file.
> > 
> > my $unix_now = time;
> > my $human_now = local_time($unix_now);
> > 
> > my $file_name = sprintf("DB_trailings.%d.%s.txt", $unix_now, $human_now);
> i want to share a few comments about log names...


> that scheme can get tedious once you have a lot of lot of logs.  i
> suggest that you use a descending date like '20020215-090105'.  if you
> ascii sort it, it's already in chronological order.  it's easy for
> humans to tab complete in their shell, and it doesn't have any spaces in
> it.

I completely agree.  I got lazy with my code.  I even forgot to
half-way clean it up, intending at least to clean up the whitespace.
That's why I put it in its own variable.

    $human_now =~ s/ /_/g;

But of course, I like the numeric version better, for the reasons you
suggest.  In fact, that's what I'd done in the past.  I got lazy in
this posting - it was the time2str that I'd forgotten.  BTW -- beware
using time in a list context.  Some of its components are one off from
what I'd expect.


> i also wanted to point out a difference in philosophy when it comes to
> reaping old log files.  you're expiring logs based on the timestamp in
> the filename, which maps to the creation time of the log.  that's one
> way to do it, but i prefer to expire the log after the last piece of
> data was written to it.  if i want to archive logs 24 hours after they
> are written, i want to archive 24 hours after the last piece of data was
> written, not the first piece of data, because i have no idea how long
> the log was open for.  if the log stays open long enough, i might end up
> expiring it while it's still being written to.  using the last write
> time has a nice side benefit, you don't have to parse the name of the
> log to figure out how to reap it, you just stat it and add the
> appropriate number of seconds to its mtime.  it's a small distinction
> and mostly philosophical, but i thought i'd provide a different
> viewpoint on that.

Good point on close time.  That makes an 'ls -l' command sort 'em by
close time, and gives you 2 pieces of info, not just one.  You can
visually look at open *and* close times.

On a site note, I just wrote a little test program that confirmed that
the mtime is set on close, not upon the last print.  By example, if
time is 0 (groovy, retro, man!!!), the mtime of the following file is
10, not 0.

    print $fh "happy zero epoch time\n";
    sleep 10;
    close $fh;


Thanks for adding the time2str function to this "stone soup", design
by committee convergence of good ideas.

Michael R. Wolf
    All mammals learn by playing!
        MichaelRunningWolf at

More information about the spug-list mailing list