[gentoo-user] How can I find all "orphaned" files?
Jarry
is there any way to find completely all "orphaned" files on my
system (recursivelly from /)? I mean all files (and directories)
which do not belong to any ebuild installed...
I know, there is "qfile" with "-o" option, but its syntax is
not clear to me. I tried "qfile -o *" but that is apparently
not the correct syntax, as all I got were a few top-level
subdirectories and nothing more...
I also found "orphan_finder.py" script in forum but I'm not
sure it works properly. When I tested it on /etc it found
a lot of "orphan" files, directories and links, which actually
are not "orphan"...
Jarry
--
_______________________________________________________________
This mailbox accepts e-mails only from selected mailing-lists!
Everything else is considered to be spam and therefore deleted.
Neil Bothwick
> I know, there is "qfile" with "-o" option, but its syntax is
> not clear to me. I tried "qfile -o *" but that is apparently
> not the correct syntax, as all I got were a few top-level
> subdirectories and nothing more...
qfile operates on the files you give it, it doesn't recurse into
directories.
Try find / -xdev -type f -exec qfile -o {} +
--
Neil Bothwick
Copper wire was invented by two Scotsmen fighting over a penny!
Dale
> On Thu, 24 Mar 2011 22:09:27 +0100, Jarry wrote:
>
>
>> I know, there is "qfile" with "-o" option, but its syntax is
>> not clear to me. I tried "qfile -o *" but that is apparently
>> not the correct syntax, as all I got were a few top-level
>> subdirectories and nothing more...
>>
> qfile operates on the files you give it, it doesn't recurse into
> directories.
>
> Try find / -xdev -type f -exec qfile -o {} +
>
>
>
Naturally this returned a lot so we have to use common sense before
deleting something. That said, what about these:
/usr/bin/cc
/usr/bin/c++
/usr/bin/c89
/usr/bin/gcc
/usr/bin/gcov
/usr/bin/x86_64-pc-linux-gnu-c++
/usr/bin/python-config
A whole bunch of files in:
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.4.5/32/*
/usr/lib64/python2.6/*
Just to name a few. Naturally there are files in /root and a lot of
files that I created that also show up. Some of the files above, they
just about have to belong to something tho. I used qfile to test and it
says they don't so your command is working fine. I'm pretty sure tho
that python-config and gcc belong to their respective packages.
Question is, why does qfile think they don't?
This is the ones I tested:
root@fireball / # qfile /usr/bin/c++
root@fireball / # qfile /usr/bin/c89
root@fireball / # qfile /usr/bin/gcc
root@fireball / # qfile /usr/bin/gcov
root@fireball / # qfile /usr/bin/x86_64-pc-linux-gnu-c++
root@fireball / # qfile /usr/bin/python-config
root@fireball / # qfile /usr/lib64/gcc/x86_64-pc-linux-gnu/4.4.5/32/
root@fireball / # qfile
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.4.5/32/crtbeginS.o
root@fireball / # qfile /usr/lib64/python2.6/binhex.pyo
root@fireball / #
Is qfile wrong? The equery command said the same as qfile so this is
confusing.
Dale
:-) :-)
P. S. Nope, I'm not deleting those. ;-)
Mr. Jarry
>
> qfile operates on the files you give it, it doesn't recurse into
> directories.
>
> Try find / -xdev -type f -exec qfile -o {} +
Oh, thanks, now it is clear. I think man-page is a little confusing:
"qfile -o" does not find orphan files, it only checkes if the given file
is orphan, or not. But first I have to prepare a list of files which
will be used as arguments for "qfile"...
Jarry
Neil Bothwick
> Naturally this returned a lot so we have to use common sense before
> deleting something. That said, what about these:
>
> /usr/bin/cc
> /usr/bin/c++
> /usr/bin/c89
> /usr/bin/gcc
> /usr/bin/gcov
> /usr/bin/x86_64-pc-linux-gnu-c++
I think these are created by gcc-config, so don't belong to any package.
If you want to do this regularly, I'd suggest creating a list of
exceptions that you can exclude from find. You don't need to search
everywhere, /{,usr}/{,s}bin, /{,usr}/lib and /opt should be sufficient.
--
Neil Bothwick
To be intoxicated is to feel sophisticated but not be able to say it.
Dale
> On Fri, 25 Mar 2011 01:33:38 -0500, Dale wrote:
>
>
>> Naturally this returned a lot so we have to use common sense before
>> deleting something. That said, what about these:
>>
>> /usr/bin/cc
>> /usr/bin/c++
>> /usr/bin/c89
>> /usr/bin/gcc
>> /usr/bin/gcov
>> /usr/bin/x86_64-pc-linux-gnu-c++
>>
> I think these are created by gcc-config, so don't belong to any package.
> If you want to do this regularly, I'd suggest creating a list of
> exceptions that you can exclude from find. You don't need to search
> everywhere, /{,usr}/{,s}bin, /{,usr}/lib and /opt should be sufficient.
>
>
So if they were deleted things would still work? Just curious. This is
a recent install so I wasn't expecting it to find much, just files I
created basically. I just thought it odd that it found so many files
and that qfile/equery didn't know where they came from either.
That gcc one bugs me tho. It's in /usr/bin but doesn't belong to a
package. Just blows my mind, which ain't much right now. lol I got
to get better meds.
Dale
:-) :-)
Neil Bothwick
> That gcc one bugs me tho. It's in /usr/bin but doesn't belong to a
> package. Just blows my mind, which ain't much right now. lol I got
> to get better meds.
Remember that gcc-config sets which version is called when you run gcc,
so it must have it's own gcc, possibly created when you change the
setting.
--
Neil Bothwick
"Everything takes longer than expected, even when you take
into account Hoffstead's Law." - Hoffstead's Law
Mike Edenfield
/usr/bin/gcc doesn't belong to any package. The gcc packages install
versioned files, like:
/usr/bin/gcc-4.5.2 ->
/usr/x86_64-pc-linux-gnu/gcc-bin/4.5.2/x86_64-pc-linux-gnu-gcc
When you run gcc-config to pick a compiler, it creates and/or updates
/usr/bin/gcc (and the others) to point to whatever version binaries you
selected.
If you deleted /usr/bin/cc, /usr/bin/gcc, etc. things would stop
compiling, but just running gcc-config will make them come back. If
/usr/bin/gcc is missing you will get an error about your GCC_SPECS being
wrong but that's because gcc-config tries to run `/usr/bin/gcc -v` to
check for problems. But the error is harmless -- just re-run gcc-config
again and you will see it finish with no problems.
--Mike
Dale
Ahhhh. So it just links the gcc command to whatever version of gcc is
active. Kewl !! That makes sense.
I learned something today. Given my age, I may forget it tomorrow but
at least I know it today. lol
I do wish there was some way to find files that are not needed or used
tho. I would still go through the files and delete them manually but it
would be nice, especially on my old rig which has a pretty old install.
I bet /etc would have quite a few of them.
Thanks to you and Neil too.
Dale
:-) :-)