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

[Michael R. Wolf]

Doug Beaver <doug at beaver.net> 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 att.net