[SunHELP] Solaris package removal question
velociraptor
velociraptor at gmail.com
Wed Aug 25 16:08:28 CDT 2004
On Wed, 25 Aug 2004 16:12:42 -0400 (EDT), Eric LeBlanc <inouk at igt.net> wrote:
> On Wed, 25 Aug 2004, Sheldon T. Hall wrote:
>
> > Eric LeBlanc says ...
> >
> > > Well, do ls -l /path/to/perl and take the creation time of
> > > this program,
> > > and do a find, something like:
> > >
> > > find / -time time_date_of_your_perl_program > /tmp/allfilesfromperl
> > >
> > > check in "man find", I can't recall what is the exact
> > > parameter (I think -ctime )
> >
> > Although some doco says ctime is "creation time," it's actually the time of
> > the last change to the inode. This may or may not be the creation time of
> > the file. UNIX doesn't seem to save the actual creation time anywhere, a
> > design blunder IMHO.
>
> You're right, I forgot this little detail. It's true that the ctime is
> the last modification of the inode, and it's the same behavior in all Unix
> system, believe me.
>
> We should use the 'mtime', it's more accurate, because it's based on a
> modification of this file.
>
> >
> > I think find's various time operators (atime, ctime, mtime) only operate on
> > whote numbers of days, too, not actual dates or times.
>
> Right, but you can build a complex expression with find, but it's may be
> very ugly (with -newer, -mtime and !).
>
> So, May I suggest something? Create a mini script perl such as:
>
> -----------------------------------------------------------------------
> #!/usr/bin/perl -w
> #($dev, $ino, $mode, $nlink, $uid, $gid, $rdev, $size, $atime, $mtime,
> # $ctime, $blocksize, $blocks) = stat($filename);
>
> $mtime = (stat("/path/to/perl"))[9];
>
> while (<STDIN>)
> {
> chomp;
> $mtime_tmp = (stat($_))[9];
>
> # let us a delay of of +- 30 seconds, or take a better delay
> if ( ($mtime < $mtime_tmp[9]+30) && ($mtime > $mtime_tmp[9]-30) )
> { print "$_\n"; }
> }
> -------------------------------------------------------------------------
>
> save it, and do this following command:
>
> find / -print | /path/to/this/script > /tmp/files
>
> How do you think ?
>
> > Which is not to say the suggestion above is useless; it's not. It's a good
> > place to start, since it will point to at least some of the files, and they
> > are likely to be in directories that have other perl files, or at least
> > files whose archiving won't hurt anything.
I can see it's all a matter of how you ask your question. :-)
I tried Eric's script, and while it generated a list of 100K files
(obviously, this "special" perl was installed during the initial
machine build), I was able to gather the perl-related files out
of this and build a tarball.
Thanks for all the help, fellows.
=Nadine=
More information about the SunHELP
mailing list