Autojump: Entrada (s) de banco de dados regularmente apagada (s)

Oi,

O mesmo problema aqui, exceto que acho que só acontece após a reinicialização.

Provavelmente corrigido por https://github.com/wting/autojump/pull/383

Aparentemente, não corrigido. Isso é realmente irritante. Qualquer ideia ?

Desculpe pela resposta tardia, mas tenho uma ideia aproximada do que está acontecendo e como consertar.

Em cada mudança de diretório, o autojump bloqueia o arquivo de dados e atualiza uma entrada, armazenada em um formato de "banco de dados". Há uma condição de corrida (exacerbada por scripts / comandos shell que percorrem diretórios como find ) em que o bloqueio falha e o banco de dados é sobrescrito.

A maneira correta de corrigir é:

1. Corrija o bloqueio de arquivo para ser seguro contra condições de corrida
2. Mude de um formato semelhante a banco de dados para um registro somente de acréscimo (como .bash_history , .zsh_history , etc), e apenas calcule os pesos quando alguém invocar autojump para alternar diretórios (também conhecido j )

Hmm, acabei de olhar o código e não vejo nenhum bloqueio real acontecendo.
Além disso, o backup é feito logo após a movimentação do arquivo temporário para o banco de dados real, então se a movimentação falhou (não há verificação de erro), estamos fazendo backup de um arquivo vazio.

Acho que melhorar isso não deve ser tão difícil.

Talvez # 383 não guardasse todos os lugares com flock , mas há uma abordagem mais simples, mas apenas envolvendo todo o autojump dentro de flock , como:
alias autojump='flock /tmp/autojump.lock autojump'

@trou você pode testar isso?

_UPD: corrigir problema de sintaxe_

Acabei de adicioná-lo ao meu bashrc, veremos.

Não parece ajudar :(

Hm, como isso pode acontecer?
Sua máquina desligou de forma anormal (por exemplo, através do botão liga / desliga)?

Também pode ser autojump chamado de sh normal (em vez de bash ) em
paralelo? Já que neste caso o alias do bash não funcionará, e neste caso você
pode tentar empacotá-lo por meio de um script, algo como:
mv /usr/bin/autojump{,.orig}
echo "flock /tmp/autojump.lock autojump.orig"> / usr / bin / autojump

Ou estou perdendo algo completamente.

Não sei, mas o problema deve ser corrigido no código de qualquer maneira.

Estou usando o autojump há cerca de um ano e, de repente, parece que ele limpou toda a história. Olhando para ~ / .local / share / autojump, vejo que um novo arquivo foi criado. Eu vi https://github.com/wting/autojump/issues/208 , que aponta aqui. Estou a usar:
autojump-22.3.2-1.fc24.noarch

Posso fornecer alguma outra informação de depuração?

Eu também faço isso regularmente. Há uma maneira de depurar isso?

@wting : Você mencionou que uma maneira de resolver o problema pode ser alternar para um "log somente para anexar" e calcular os pesos quando o autojump for executado.

Suponho que você esteja evitando essa solução porque o log pode se tornar proibitivamente longo com o tempo. (E, também, porque seria bom se o sistema existente funcionasse da maneira que achamos que deveria.)

Mas talvez uma solução híbrida seja possível? Anexe entradas a um log, mas adicione um comando autojump que as converte para o formato de banco de dados. Quando o autojump é executado, consulte o log e o banco de dados para calcular os pesos reais.

A principal desvantagem disso é que exige que o usuário reduza o banco de dados manualmente. Uma solução alternativa seria fazer um teste aleatório sempre que o autojump for executado para determinar se o banco de dados deve ser recolhido. Isso, pelo menos, diminuiria as chances de uma condição de corrida.

@azat : Vou tentar sua solução.

Desde que implementei um patch proposto em # 482, não encontrei esse bug.

No entanto, também estou interessado em ouvir os resultados do @ r-barnes. Se for bem-sucedido, há algum motivo para esse "bloqueio antecipado" não poder ser usado no autojump?

Argh! Recebi uma atualização que substituiu o patch de # 482. Aconteceu na próxima reinicialização. Não entendo como outras pessoas não estão passando por isso. Isso acontece comigo constantemente.

Não tive 100% de sucesso com # 482. O banco de dados ainda parece estar limpo ou, talvez, seu tamanho seja limitado. Não parece crescer muito além de 23 entradas para mim.

Tive 100% de sucesso com # 482. 21 de abril até 25 de julho. Tenho 279 entradas atualmente. Isso sugere que nossas situações são diferentes, o que significa que há vários gatilhos para esse bug. O que quer que eu esteja fazendo para causar isso, está sempre relacionado aos diferentes sistemas de arquivos que o autojump usa para gerenciar o banco de dados, como sugeriu @Frefreak . E, como sugeri, pode haver vários caminhos de código que levam ao mesmo bug, alguns dos quais, eu nunca uso, mas você usa.

Ah, aconteceu novamente algum dia na semana passada, depois de tanto tempo desde a última vez. 349 entradas foram removidas, o tamanho do arquivo diminuiu de 93K para 77K.

alguma atualização?

Acabei desenvolvendo minha solução (somente zsh). Muito menor, mais útil e mais confiável :)
https://github.com/kurkale6ka/zsh (o README nesse link)

Parece que aqui estão várias alternativas existentes. Estou tentando 'fasd' agora https://github.com/clvv/fasd , que é apenas um.

Veja https://github.com/rupa/z/issues/198 - relatório de bug semelhante em outro projeto que tem um problema semelhante.
Não consigo encontrar uma solução semelhante ao autojump que funcione :(

Para sua informação, não tive esse problema por mais de um ano depois que mudei o arquivo temporário para o mesmo diretório do arquivo de dados. O patch é:

--- autojump_data.py    2018-09-07 15:28:30.488681864 +0800
+++ /usr/bin/autojump_data.py   2017-08-26 15:43:50.136781805 +0800
@@ -120,11 +120,12 @@

 def save(config, data):
     """Save data and create backup, creating a new data file if necessary."""
-    create_dir(os.path.dirname(config['data_path']))
+    data_dir = os.path.dirname(config['data_path'])
+    create_dir(data_dir)

     # atomically save by writing to temporary file and moving to destination
     try:
-        temp = NamedTemporaryFile(delete=False)
+        temp = NamedTemporaryFile(delete=False, dir=data_dir)
         # Windows cannot reuse the same open file name
         temp.close()

Mover arquivos entre dispositivos não é atômico (faz uma operação de copiar + excluir), portanto, eles devem ser colocados no mesmo dispositivo para sobrescrever atomicamente.

Isso faz muito sentido para mim. Um movimento só é atômico se estiver na mesma partição ...

Isso é implementado na v22.5.2 aqui: https://github.com/wting/autojump/commit/bc4ea615462adb15ce53de94a09cec30bcc5dc0a

Por enquanto, instale e teste da fonte e informe se os dados ainda estão sendo perdidos.

Acho que abri um pull request # 495 com a mudança no ano passado, mas passou despercebido.

Ops, eu reverti https://github.com/wting/autojump/commit/bc4ea615462adb15ce53de94a09cec30bcc5dc0a e mesclei suas alterações em https://github.com/wting/autojump/commit/8fffbad95ac5626f4d9688276ba8a8a36808c

Não tenho certeza se o tempo é suficiente para o teste, mas não tenho problemas com a limpeza do banco de dados. O que você acha @wting. E se for certo para você, você pode criar um novo lançamento, para que as distros possam pegar?

Comecei a sofrer com esse problema de limpeza. Após várias horas, autojump.txt é eliminado. Como depurar?

Recentemente, notei que o autojump não funcionou conforme o esperado. Então eu verifiquei para encontrar:

[hendry<strong i="6">@t480s</strong> ~]$ wc -l ~/.local/share/autojump/autojump.txt
35 /home/hendry/.local/share/autojump/autojump.txt

Er ... parece ter sido reiniciado. Alguma ideia POR QUÊ?

Havia uma condição de corrida que ocasionalmente apagava a entrada do banco de dados corrigida na v22.5.3.

@minjang , @kaihendry : autojump -v e compartilhar o número da versão listada? Se for inferior a essa versão, atualize e / ou instale a partir do código-fonte.

[hendry<strong i="5">@t480s</strong> ~]$ autojump -v
autojump v22.5.1
[hendry<strong i="6">@t480s</strong> ~]$ pacman -Qi autojump
Name            : autojump
Version         : 22.5.1-2
Description     : A faster way to navigate your filesystem from the command line
Architecture    : any
URL             : https://github.com/wting/autojump
Licenses        : GPL3
Groups          : None
Provides        : None
Depends On      : python
Optional Deps   : None
Required By     : None
Optional For    : None
Conflicts With  : None
Replaces        : None
Installed Size  : 121.00 KiB
Packager        : Felix Yan <[email protected]>
Build Date      : Sat 10 Nov 2018 06:58:45 AM
Install Date    : Wed 14 Nov 2018 08:57:48 AM
Install Reason  : Explicitly installed
Install Script  : No
Validated By    : Signature

Sou um usuário do Archlinux btw: rofl:

Em 18.04.2 LTS, eu tenho v22.5.1. Não tenho certeza se a atualização foi feita para os repositórios Debian / Ubuntu, ou se a versão foi congelada. Atualização instalada: vamos ver como funciona! (Muito obrigado.)

Não tenho certeza de quem mantém o pacote Debian para autojump atualmente, mas é possível que eles apenas criem tags estáveis. Embora o branch master esteja na v22.5.3 por mais de 6 meses, marquei apenas a v22.5.3 esta noite.

Sua melhor aposta para lidar com essa perda aleatória de dados é instalar a partir da fonte seguindo estas instruções .