file timestamps and removal [was Re: SPUG:DOS / BASIC Script]
Michael R. Wolf
MichaelRunningWolf at att.net
Sat Jan 18 17:44:49 CST 2003
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
More information about the spug-list
mailing list