☰

다음 중 실제 고아(분실) 파일이고 안전하게 삭제할 수 있는 파일은 무엇입니까?

tag-icon • tag-icon files package-management
다음 중 실제 고아(분실) 파일이고 안전하게 삭제할 수 있는 파일은 무엇입니까?

이라는 프로그램을 사용하고 있어요잃어버린 파일내 Arch Linux 시스템의 어떤 패키지에도 속하지 않는 모든 고아(누락) 파일을 나열합니다.

대부분의 파일에 대해 안전하게 삭제할 수 있다고 확신하거나 적어도 해당 파일이 어디서 왔는지 알고 있지만 다음 파일에 대해서는 삭제해도 안전할지 확신할 수 없습니다.

# It is not maintained by any package but can I safely delete it?
/core 

# still used by gtk2?
/etc/gtk-2.0/gdk-pixbuf.loaders 

/etc/pango/pango.modules
/etc/pango/pango.modules-32

/etc/.pwd.lock

# Not owned by udev?
/etc/udev/hwdb.bin 

/etc/xdg/gtk-2.0

/etc/xml/catalog

# not owned by ruby?
/usr/bin/update_rubygems 

# Can I safely delete these cache files?
/usr/lib32/gdk-pixbuf-2.0/2.10.0/loaders.cache
/usr/lib32/gtk-2.0/2.10.0/immodules.cache
/usr/lib32/libffi-3.0.12
/usr/lib32/libffi-3.0.12/include
/usr/lib32/libffi-3.0.12/include/ffi.h
/usr/lib32/libffi-3.0.12/include/ffitarget.h
/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache
/usr/lib/gio/modules/giomodule.cache
/usr/lib/gtk-2.0/2.10.0/immodules.cache
/usr/lib/gtk-3.0/3.0.0/immodules.cache

# Generated by locale-gen?
/usr/lib/locale/locale-archive

# I can safely remove the cache file?
/usr/share/applications/mimeinfo.cache

/usr/share/glib-2.0/schemas/gschemas.compiled
/usr/share/gtk-doc/html/gtk2/AbstractObje....html

/usr/share/info/dir
/usr/share/libgphoto2
/usr/share/libgphoto2/asus_oled.ko.gz

# Am I safe to delete the timestamp history?
/var/db/sudo/orschiro
/var/db/sudo/orschiro/0
/var/db/sudo/orschiro/1
/var/db/sudo/orschiro/2
/var/db/sudo/orschiro/3
/var/db/sudo/orschiro/4
/var/db/sudo/orschiro/5
/var/db/sudo/orschiro/6
/var/db/sudo/orschiro/7
/var/db/sudo/orschiro/8
/var/db/sudo/orschiro/pid12778
/var/db/sudo/orschiro/pid14461
/var/db/sudo/orschiro/tty1
/var/db/sudo/orschiro/tty2
/var/db/sudo/orschiro/tty4
/var/db/sudo/test

답변1

안 된다고 할 테니 삭제하지 마세요.최대그것들. 나는 이것들 중 일부가 패키지의 일부라고 믿습니다. 당신은 그것을 어떻게 결정했는지 말하지 않았습니다.

이 중 일부는 찢어진 패키지에서 남아 있을 수 있습니다. 예를 들어 구성 파일이 변경되었거나 다른 것이 이를 사용할 수 있다고 믿을 만한 이유가 있는 경우 이러한 일이 발생할 수 있습니다. 그 중 일부는 이 범주에 속하며 단지 빈 디렉토리일 수 있습니다. 어쨌든, 이것들은 사소한 것이므로 걱정할 가치가 없습니다.

내 생각에는 당신이 하는 일에는 두 가지 이유가 있을 수 있습니다.

  • 파일 시스템을 깔끔하게 유지하고 공간/inode를 절약하고 싶습니다.

모든 바이트가 중요한 임베디드 시스템을 다루지 않는 한 무엇을 하든 상관이 없습니다. 그러한 시스템을 다루고 있다면 이는 공간을 절약하는 데 있어 매우 열악하고 비효율적인 방법입니다.

  • 당신은 알려지지 않은 파일에 대해 편집증적입니다.

이것이 더 나은 이유이기는 하지만 여전히 유효하지 않습니다. 이 방법으로는 콘텐츠를 추적할 수 없으며 저장 공간이 필요한 경우 잘 아는 침입자가 해당 파일을 간단히 교체할 수 있습니다. 파일 시스템 변경 측면에서 침입을 모니터링하려면 감시 목록이 아닌 실제로 이를 모니터링하거나 간헐적으로 검사하는 것이 필요합니다. 한 사람이 이 일을 효과적으로 수행하기에는 추적해야 할 것이 너무 많습니다. 이러한 목적으로 설계된 자동화 시스템을 사용하는 방법을 배우는 데 시간을 투자한다면 더 좋을 것입니다.

즉, 제거해도 안전하다고 생각되는 몇 가지 사항이 있습니다.

# It is not maintained by any package but can I safely delete it?
/core

최근(예: 마지막 부팅 이후)에 건드리지 않은 크고 두꺼운 바이너리라면 그렇습니다. core파일은 디버그 덤프이며 때로는 충돌한 응용 프로그램으로 인해 남겨집니다.

# Am I safe to delete the timestamp history?

로그와 같은 것들은 분명히 한동안 액세스되지 않았습니다(예:오래된로그)을 삭제해도 안전할 수 있습니다. 혹시라도 /trash실제로 삭제하기 전에 잠시 동안 디렉터리로 이동하겠습니다. 전체 경로를 휴지통 디렉터리에 복사하면 필요한 경우 쉽게 복원할 수 있습니다.

답변2

/core는 크래시 덤프이므로 안전하게 삭제할 수 있습니다.http://en.wikipedia.org/wiki/Core_dump

나머지는 모르겠습니다. .

답변3

get core-files... 이 파일은 프로그램이 충돌할 때 생성됩니다. 운영 체제는 기본적으로 충돌이 발생한 프로세스에 속한 메모리의 내용을 가져와서 파일에 씁니다. core- 파일은 디버거를 사용하여 분석할 수 있으므로 개발자에게 매우 유용합니다. 그러나 효과적인 디버깅에 필요한 추가 항목을 제거하는 미리 패키지된 바이너리를 사용하는 일반 사용자(즉, 우리 대부분의 경우)의 경우 core-files는 많은 공간을 차지하므로 안전하게 제거할 수 있습니다. 사실, find정기적으로 실행하여 오래된 파일을 찾아 삭제하는 것이 core아마도 좋은 생각일 것입니다(잘 사용 ) cron. core- 파일은 일반적으로 프로그램이 "실행"되는 디렉터리에 생성되므로 일반적으로 사용자의 홈 디렉터리에 위치합니다.

이상한 코어 파일은 큰 문제가 아니지만, 동일한 프로그램이 항상 충돌하거나 코어 파일을 생성하는 경우 이는 더 심각한 문제를 나타낼 수 있습니다(코어 파일은 하위 프로세스에 의해 생성될 수 있으며, 이 경우에도 충돌이 발생하므로 생성된 경우 코어 파일을 삭제하더라도 메인 프로그램은 계속 실행될 수 있습니다. 코어 파일의 크기를 제한하거나 코어 파일 생성을 끌 수 있습니다. 이는 대부분의 배포판이 일반 사용자를 위해 수행하는 작업입니다. (명령어로 하면 될 것 같은데 ulimit...)

이 파일이 루트 바로 아래에 있다는 사실은 core루트 사용자가 실행하는 일종의 프로그램이 충돌했다는 것을 의미합니다. 먼저 살펴보고 그것이 어떤 프로그램인지 알아낼 수 있는지 확인하는 것이 좋습니다. ( less충분해야 합니다... 바이너리 횡설수설이지만 일반적으로 혼란 속에서 프로그램 이름을 발견할 수 있습니다) 를 클릭한 다음 자주 오류가 발생하는지 확인하세요.

관련 정보