Arquivo invisível com um nome real específico - não é possível listá-lo, excluí-lo ou criar um novo arquivo com esse nome

Question

Parece que tenho uma pasta 'invisível' que não consigo ver nem excluir, mas está bloqueando a criação de um arquivo 'real'.

Eu estou em uma caixa vagabunda (Ubuntu 14)

Eu estava tentando instalar o pacote link do Python, mas pareceu acertar esse problema link então eu alterei o script de inicialização para não criar links simbólicos (com a intenção de que ele copiasse os arquivos via shutil.copy2 )

De qualquer forma, ainda falhou com o Protocol Error ... no entanto, esta não é a minha pergunta, apenas o plano de fundo.

Agora, parece que tenho uma pasta / arquivo 'invisível' apptrace que não consigo ver nem excluir, mas estou bloqueando a criação de um arquivo 'real':

$ sudo ls -la
total 6640
drwxr-xr-x 1 vagrant vagrant    1326 Oct 14 11:08 .
drwxr-xr-x 9 vagrant vagrant    4096 Oct 14 11:46 ..
-rw-r--r-- 1 vagrant vagrant    1722 Oct 14 09:46 appengine_config.py
-rw-r--r-- 1 vagrant vagrant    1077 Oct 14 09:59 appengine_config.pyc
-rw-r--r-- 1 vagrant vagrant     760 Oct 14 09:33 app.yaml
drwxr-xr-x 1 vagrant vagrant     170 Oct  8 10:24 campaigns

e:

$ file *
appengine_config.py:          Python script, ASCII text executable
appengine_config.pyc:         python 2.7 byte-compiled
app.yaml:                     ASCII text
campaigns:                    directory

e:

$ rm -rf apptrace
rm: cannot remove ‘apptrace’: Is a directory
$ rm -r apptrace
rm: cannot remove ‘apptrace’: No such file or directory
$ sudo vi apptrace
(says [Permission Denied] at bottom of screen, despite sudo, and can't be saved)
$ cd apptrace
apptrace$ <-- worked
apptrace$ sudo ls -la
ls: cannot open directory .: Operation not permitted
apptrace$ sudo vi newfile
(does NOT say [Permission Denied] but fails E212: Can't open file for writing on save)

(todos os comandos acima são executados enquanto são enviados para a caixa vagabunda)

Por favor me ajude! :)

    

Answer 1

Lendo um pouco, como aqui: link , parece que eu poderia ter terminado com um inode órfão.

Lendo um pouco mais, parecia que eu precisava rodar a ferramenta fsck para consertar o, er, thingamijigs.

Você não pode executar fsck em um sistema de arquivos que esteja montado, pelo menos não sem conseqüências terríveis, de acordo com o fsck em si.

No entanto, eu li que o Linux rodará fsck na inicialização, então a correção para o meu problema foi apenas reinicializar a caixa do vagrant.

Eu adoraria ouvir mais respostas se você souber como direcionar especificamente o órfão específico sem reiniciar o servidor, ou se você tem alguma pista sobre como esse órfão foi criado em primeiro lugar.

    

Answer 2

cd apptrace

_

ls -lisa:
--------
4110     24 drwxrwxrwt 20 root  root      12288 Okt 14 17:52 .
   2      8 drwxr-xr-x 22 root  root       4096 Sep 11 13:27 ..
....

_

cd ..

_

sudo find . -inum 4110 -delete

deve deletar seu diretório / arquivo órfão