[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