次のうち、実際の孤児(紛失)ファイルであり、安全に削除できるファイルは何ですか?

次のうち、実際の孤児(紛失)ファイルであり、安全に削除できるファイルは何ですか?

というプログラムを使っています。失われたファイル私の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

ダメだから削除しないでください。最大それら。私はこれらのいくつかがパッケージの一部であると信じています。あなたはそれをどのように決めたのか言わなかった。

これらのいくつかは破れたパッケージに残ることがあります。たとえば、設定ファイルが変更された場合、または他のものがそれを使用できると信じる理由がある場合、これが発生する可能性があります。そのうちのいくつかはこのカテゴリに属し、空のディレクトリになることがあります。とにかく、これらは些細なものなので、心配する価値はありません。

私の考えでは、あなたがすることには2つの理由があるかもしれません。

  • ファイルシステムをきれいに保ち、スペース/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に削除する前に、しばらくの間ディレクトリに移動します。フルパスをごみ箱ディレクトリにコピーすると、必要に応じて簡単に復元できます。

おすすめ記事