☰

패키지 관리자가 설치하지 않은 파일 찾기

tag-icon • tag-icon find gentoo symlink
패키지 관리자가 설치하지 않은 파일 찾기

패키지 관리자(포티지)에 의해 설치되지 않은 젠투 리눅스 시스템의 모든 파일 목록을 얻고 싶습니다. 주변에 있는 불필요한 파일을 모두 제거하여 시스템을 최대한 깨끗하게 유지하고 싶기 때문입니다.

지금까지 제가 시도한 것을 말씀드리겠습니다. 먼저 포티지가 추적하는 패키지에 속하는 모든 파일 목록을 생성합니다:

equery files "*" | sort | uniq > portage.txt

그런 다음 관심 없는 파일을 제외하고 시스템의 모든 파일 목록을 생성합니다.

find / \( -path /dev -o -path /proc -o -path /sys -o -path /media \
          -o -path /mnt -o -path /usr/portage -o -path /var/db/pkg \
          -o -path /var/www/localhost/htdocs -o -path /lib64/modules \
          -o -path /usr/src -o -path /var/cache -o -path /home \
          -o -path /root -o -path /run -o -path /var/run -o -path /var/tmp \
          -o -path /var/log -o -path /tmp -o -path /etc/config-archive \
          -o -path /usr/local/portage -o -path /boot \) -prune \
          -o -type f | sort | uniq > all.txt

마지막으로 포티지가 추적하지 않는 모든 파일 목록을 얻었습니다:

comm -13 portage.txt all.txt > extra.txt

일부 통계:

wc -l portage.txt all.txt extra.txt
  127724 portage.txt
   78371 all.txt
    8438 extra.txt

보시다시피, 아직 8,000개가 넘는 추가 파일이 있습니다. 실제로 삭제해야 하는 파일에 더 집중하기 위해 이 숫자를 줄이고 싶습니다.

, 및 extra.txt와 같은 몇 개의 디렉토리에 수천 개의 파일이 있다는 것을 알았습니다 . 예를 들어, 파일 위치에 내 시스템에 . 에 대한 심볼릭 링크가 있으므로 더 나은 결과를 얻으려면 심볼릭 링크를 적절하게 처리해야 할 것 같습니다. 어쩌면 그들이 가리키는 모든 파일을 추가함으로써 가능합니다 . 나는 정말로 무엇을 해야할지 모르겠습니다./usr/lib64/gcc/usr/lib64/python2.7/usr/lib64/python3.2/usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.3/crtbegin.oportage.txt/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/crtbegin.o/usr/lib/usr/lib64portage.txt

또한 왜 portage.txt보다 큰가 all.txt? 포티지가 추적하는 파일은 내 시스템에 있는 모든 파일의 하위 집합이기 때문에 반대 방향이어야 하지 않나요?

find마지막으로 명령에서 제외해야 하는 다른 위치를 잊어버렸습니까?

답변1

당신이 찾고 있는 것은 qfile. 패키지의 일부이며 옵션 app-portage/portage-utils을 제공합니다 . 당신은 다음과 같은 것을 사용할 수 있습니다-o--orphans

find /usr/bin -type f | xargs -I{} qfile -o {}

에서 고아 파일 목록을 가져옵니다 /usr/bin.

참고: 불행하게도 qfile현재 안정 버전의 portage-utils에서는 stdin에서 읽는 것이 지원되지 않으며 qfile 매뉴얼 페이지에 언급된 해결책은 qfile -o $(find /usr/bin)조회 결과 집합이 클 때 작동하지 않으므로 이를 해결해야 합니다. 클릭하여 사용하세요 xargs.

그건 그렇고, 나는 이것을 스스로 생각하지 않았습니다.헤어스프링 스레드, yvasilev의 리뷰.

답변2

portage.txt다음 명령을 실행하여 심볼릭 링크 관련 문제를 해결했습니다.

equery files '*' | while read i; do readlink -e "${i}"; done | sort | uniq \
       > portage.txt

portage.txt이는 심볼릭 링크 자체가 아니라 심볼릭 링크가 가리키는 파일을 넣는 데 사용됩니다 . find생성된 명령은 심볼릭 링크를 나열하지 않고 심볼릭 링크가 가리키는 파일만 나열 하므로 이 작업이 필요합니다 all.txt. 그렇지 않으면 많은 오탐이 발생하게 됩니다. 이 명령은 수천 개의 파일에서 실행되기 때문에 상당히 느린 명령이지만 readlink더 나은 솔루션을 찾을 수 없습니다. 어떤 제안이라도 환영합니다.

내가 이해하는 또 다른 점은(이것이 더 쉽습니다) portage.txt비율이 더 큰 이유입니다 all.txt. 이는 /usr/src명령 결과에서 디렉토리와 그 아래의 모든 파일을 명시적으로 제거했지만 find어쨌든 equery나열되었기 때문입니다 .

이것이 문제가 아니더라도 내가 마지막으로 한 일은 Python 항목(주로 또는 접미사가 붙은 파일 및 파일 __pycache__)을 무시하는 것이었습니다..pyc.pyo

grep '\(\.cpython-32\)\?\.py[co]$\|/__pycache__' candidates.txt \
     > candidates-bytecode.txt
sed -e 's/\(\.cpython-32\)\?\.py[co]$/.py/' \
    -e 's/\/__pycache__//' \
    candidates-bytecode.txt | sort | uniq \
    > candidates-bytecode-source.txt
comm -23 candidates-bytecode-source.txt portage.txt \
     > orphaned-bytecode.txt

이렇게 하면 모든 Python 항목의 출처를 추적하고 거기에 있는지 확인할 수 있습니다 portage.txt. 보시다시피 동일한 정규 표현식을 두 번(명령에 대해 한 번 grep, 명령에 대해 한 번) 작성했지만 sed어쩌면 한 단계만으로 완료될 수도 있습니다. .

답변3

IIRC, 젠투는 패키지 정보를 일반 텍스트(아마도 /var/db/)로 저장하므로 직접 검색하는 것이 느릴 수 있습니다.

가장 좋은 방법은 모든 패키지 파일에 대한 sqlitedatabase(또는 임의의 데이터베이스)를 생성한 다음 시스템의 모든 파일을 나열하고 데이터베이스에서 하나씩 찾아보는 것입니다. 찾을 수 없으면 포티지에 속하지 않습니다.

관련 정보