|
Re: File Aging in UNIX system
by rsteinke (Scribe) on Aug 17, 2004 at 15:00 UTC
|
This is a fairly standard unix-y thing, so instead of using
perl, consider using the 'find' utility:
find <root dir> -atime +<days> -mtime +<days>
where <days> is the number of days in the last six months,
and <root dir> is the root of the diretory tree you're searching (/ for the whole system, but it's much faster if you can just search /home for user files or something).
The options I've given come from the gnu version of find,
on linux. Read the man page on your local system to make
sure they're correct for you.
Ron Steinke
<rsteinke@w-link.net>
| [reply]
[d/l] |
Re: File Aging in UNIX system
by Joost (Canon) on Aug 17, 2004 at 15:06 UTC
|
Erm, excuse me, but you're not very clear to me.
I started out with stat(), but got "odd" results, so switched to ls using the -u and -c switches.
What are "odd" results? Did they not give the same results as the "ls" command?
On three servers, no files show up in my report as being untouched for more than six months. On another, only one file "failed" the test.
What consitutes a failed test?
For one thing, when I log onto a server and just do a vanilla "l" of a directory--say, /usr/local/...--I get file dates ranging back as far as 1997.
Which says nothing about access time.
I use JDNs to compare the dates. On the server with a 92% failure rate, nearly all files had the same access and modification dates. This led me to suspect cloning, but since that just creates a binary image, the dates should be those on the master drive, not the date of the cloning, or so I've been told.
What's JDNs? What's cloning? What's a "master drive"? Do you by any chance make backups? If so, how, and have you ever restored them?
Which OS and file system are you using?
Joost
| [reply] |
Re: File Aging in UNIX system
by borisz (Canon) on Aug 17, 2004 at 14:59 UTC
|
Do it yourself with File::Find or use the unix command find to do that.
| [reply]
[d/l] |
|
|
Thanks for the suggestion, Boris, but find uses the same mtime and ctime (or was it atime?) that ls gives--I thought of that, too.
Thanks any-hoo!
| [reply] |
Re: File Aging in UNIX system
by bluto (Curate) on Aug 17, 2004 at 15:05 UTC
|
Show us, with code and output, why the results to stat are "odd" (e.g. "ls -l /server/file", and the mtime and atime results from stat for the same file).
FWIW, 'stat' is pretty basic stuff. If on the slim chance that stat is actually broken in your copy of perl, then you might as well not use perl until you get an unbroken version (i.e. don't try using other solutions -- figure out why stat is "odd" first).
bluto
| [reply] |
|
|
Bluto,
Perhaps I was inaccurate in calling stat() broken, it's just that it was the first pass at things (code/results no longer available). As I sit here in a funk, pondering such animules, it seems that I was probably getting the same results as the later incarnation using the ls commands. Sorry for the misleading.
Thanks.
| [reply] |
Re: File Aging in UNIX system
by gaal (Parson) on Aug 17, 2004 at 18:45 UTC
|
I know some admins turn off atime because of purported slowdowns it incurs. I don't know how common (or correct) this practice is. | [reply] |
Re: File Aging in UNIX system
by Aristotle (Chancellor) on Aug 18, 2004 at 11:42 UTC
|
ls, find, and friends are not relying on some kind of magic to get their data. They call the system stat call. That's exactly what Perl does for its stat builtin, as well.
If the results you get using Perl are odd, for some value of "odd", then so will the results of any other tool be.
The reason is with your systems, not Perl.
Makeshifts last the longest.
| [reply] |