Estou tendo um problema estranho que deve ser causado pelo VIM, pelo cache VFS do Linux, pelo ecryptfs e / ou por algo relacionado ao sistema de arquivos:
O arquivo deve estar acessível assim que :w relatar o arquivo como está escrito.
O arquivo não existe.
Se eu esperar um pouco (geralmente menos de um segundo), o arquivo aparece.
Isso é especialmente complicado quando se trabalha com código Python e sobra os arquivos pyc . Muitas vezes acabei começando o código antigo, pois o novo arquivo py ainda não estava pronto. Recentemente, adicionei export PYTHONDONTWRITEBYTECODE=1 ao meu .bashrc , para obter uma mensagem de erro significativa em vez de executar o código antigo. Ainda é muito estranho como qualquer código de recarregamento automático (por exemplo, do Django) não consegue recarregar a cada 5-10 vezes porque o arquivo que eu mude desaparece por um curto período de tempo. Com os arquivos pyc instalados, o recarregador automático às vezes acabou carregando o antigo arquivo pyc e depois disso nunca foi descoberto que o arquivo py foi modificado e disparou outro recarregamento.
Minha máquina tem muita RAM (32 GiB), um SSD e é basicamente inativa. Portanto, não acho que a E / S lenta esteja causando isso. O arquivo é muito pequeno (< 1 KiB) e também acontece com arquivos vazios. Eu estou usando um crypt $HOME usando o ecryptfs, então isso pode ser parte do problema. Não consegui reproduzir isso na minha /tmp mount, que usa um sistema de arquivos tmpfs .
O motivo pelo qual o arquivo é removido e substituído por um novo arquivo é causado por minhas configurações do VIM:
set backup
set backupskip=
set backupdir=$HOME/.vimbackup
set writebackup
Eu esperaria que o arquivo new estivesse acessível logo após o VIM relatar que o arquivo foi gravado. Eu verifiquei a documentação do VIM para quaisquer sugestões de uma gravação atrasada, mas não encontrei nada. Não consegui reproduzir isso usando os comandos shell mv , cp e rm , então acho que o VIM está fazendo algo diferente.
O que mais poderia estar causando isso? Como posso resolver isso?
Este é um bug, mas não está relacionado ao que o Aaron vinculou. Eu não consigo reproduzi-lo no momento, então você pode por favor arquivar um novo bug aqui: link
Você pode copiar e colar a partir da descrição acima, mas eu também preciso saber mais sobre a distribuição Linux e a versão do kernel que você está usando. Obrigado!
Provavelmente é um defeito de bug / design no ecryptfs. Veja este relatório de erros da barra de lançamento .
Em suma, o ecryptfs simplesmente não grava o arquivo no disco imediatamente. Meu palpite é por causa da sobrecarga de criptografia (o sistema de arquivos provavelmente criptografa os dados em um thread de segundo plano e os grava apenas depois que eles são concluídos).
O bug é de 2009 e a prioridade é "Wishlist" (abaixo de "Low"). Estou um pouco preocupado com o quão " empreendimento " e tal comportamento se mistura; como você descobriu, muitos códigos esperam que os arquivos sejam utilizáveis imediatamente após salvá-los.
Tente usar TrueCrypt em seu lugar.
Eu acho que o comportamento que você vê é apenas porque o processo de backup do Vim é lento. No meu sistema ext4 simples, esse problema se manifesta como um erro "arquivo está vazio" do compilador.
Para verificar os horários, usei esta sequência de Bash:
strace -tt -o /dev/stdout gvim --nofork main.cxx | grep 'main.cxx\|close'
Com os backups ativados, vejo um intervalo de 200 ms entre o arquivo desaparecer e finalmente ser salvo:
09:06:49.587341 rename("main.cxx", "main.cxx~") = 0
09:06:49.668654 open("main.cxx", O_WRONLY|O_CREAT|O_TRUNC, 0644) = 12
09:06:49.755454 close(12) = 0
Quando eu uso set nowritebackup no meu .vimrc , o arquivo não é renomeado; há apenas um aberto e um próximo:
09:19:45.731416 open("main.cxx", O_WRONLY|O_CREAT|O_TRUNC, 0644) = 12
09:19:45.815763 close(12) = 0
Esta é uma boa explicação para o problema que você está enfrentando?
P.S. Não foi possível encontrar outra menção a este problema no Rastreador de problemas do Vim ou no Vim desenvolvedor / listas de discussão do usuário, por isso não posso dizer se a equipe do Vim consideraria alterar a sequência de chamadas do sistema de backup.