Qual dos seguintes arquivos são arquivos órfãos (perdidos) e podem ser removidos com segurança?

0

Estou usando um script chamado lostfiles para listar todos os arquivos órfãos (perdidos) que não pertencem a nenhum pacote no meu Arch. Sistema Linux.

Embora para a maioria dos arquivos eu tenha quase certeza de que posso deletá-los com segurança ou pelo menos saber de onde eles vêm, para os arquivos a seguir, não tenho certeza se é seguro removê-los.

# 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
    
por orschiro 11.11.2013 / 12:33

3 respostas

2

Vou dizer não, não apague mais deles. Alguns deles, acredito, fazem parte de um pacote - você não disse como determinou isso.

Alguns deles podem ter sobrado de um pacote removido; isso pode acontecer se, por exemplo, um arquivo de configuração for alterado ou se houver algum motivo para acreditar que algo possa ser usado. Alguns deles provavelmente se enquadram nessa categoria e são apenas diretórios vazios. De qualquer forma, essas são coisas infinitesimais e não vale a pena se preocupar.

Eu vejo dois motivos possíveis para fazer o que você está fazendo:

  • Você deseja manter seu sistema de arquivos organizado e economizar espaço / inodes.

A menos que você esteja lidando com um sistema embarcado em que cada byte conta ou algo assim, o que você está fazendo será irrelevante. E se você está lidando com tal sistema, este seria um método muito pobre e ineficaz de tentar economizar espaço.

  • Você é paranoico com arquivos desconhecidos.

Esta é uma razão melhor, mas ainda deve ser ineficaz; não há como você rastrear as coisas dessa maneira, e um intruso meio experiente pode simplesmente substituir os arquivos que pertencem se ele precisar de armazenamento. Se você quiser observar a invasão em termos de alterações no sistema de arquivos, você precisa de algo que realmente monitore ou analise de forma intermitente - não uma lista de olhos. Há simplesmente muito a ser seguido para que uma pessoa faça isso de forma eficaz. Você está muito melhor usando seu tempo aprendendo a usar um sistema automatizado projetado para essa finalidade.

Dito isto, há algumas coisas que acredito serem seguras para remover:

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

Se este é um arquivo binário grande e gordo que não foi tocado recentemente (como em sua última inicialização), então sim. core arquivos são depósitos de depuração, às vezes deixados para trás por aplicativos que falharam.

# Am I safe to delete the timestamp history?

Coisas como logs que obviamente não foram acessados por um tempo (isto é, logs antigos ) provavelmente são seguros para serem removidos. Apenas por precaução, eu mudaria isso para algum lugar por algum tempo - para um diretório /trash - antes de excluí-los. Se você copiar todo o caminho para o diretório da lixeira, será fácil restaurá-los, se necessário.

    
por 11.11.2013 / 13:14
1

/ core é um despejo de memória, seguro para remover o link

O resto, eu não sei. .

    
por 11.11.2013 / 13:01
0

Para pegar core -files ... Estes são feitos quando um programa trava. O sistema operacional basicamente pega o que está na memória pertencente ao processo que falha e o grava em um arquivo. core -files pode ser muito útil para desenvolvedores, já que um depurador pode ser usado para analisá-lo. Mas para usuários normais usando binários pré-empacotados sem o material extra necessário para uma depuração eficaz (ou seja, para a maioria de nós), core -files ocupa muito espaço e pode ser excluído com segurança. Na verdade, executar find regularmente para localizar e excluir antigos core -files pode ser uma boa ideia (um excelente uso de cron ). core -files geralmente são criados no diretório do qual um programa é "executado a partir de", então eles geralmente estão nos diretórios base do usuário.

O arquivo principal ímpar não é um grande problema, mas se o mesmo programa sempre falhar e / ou criar arquivos core, pode mostrar um problema mais sério (arquivos principais podem ser criados por sub-processos e tais que falha também, portanto, o programa principal pode continuar a ser executado mesmo que um arquivo principal tenha sido criado). É possível limitar o tamanho ou desativar a criação de arquivos principais, o que a maioria das distros faz para usuários normais. (Pense que isso pode ser feito com o comando ulimit ...)

O fato de que esse core -file é colocado diretamente sob a raiz, mostra que é algum tipo de programa executado pelo usuário-raiz que travou. Pode ser uma boa idéia olhar para ele primeiro, para ver se você pode descobrir qual programa era ( less deve ser o suficiente ... É um texto binário, mas normalmente você conseguirá identificar o nome do programa em a bagunça) e, em seguida, verifique se está se comportando de maneira regular.

    
por 11.11.2013 / 16:20