Autojump: Entrée (s) de base de données régulièrement effacée

Salut,

Même problème ici sauf que je pense que cela n'arrive qu'après le redémarrage.

Probablement corrigé par https://github.com/wting/autojump/pull/383

Apparemment pas fixé. C'est vraiment ennuyeux. Une idée ?

Désolé pour la réponse tardive, mais j'ai une idée approximative de ce qui se passe et comment y remédier.

A chaque changement de répertoire, le saut automatique verrouille le fichier de données et met à jour une entrée, stockée dans un format de type «base de données». Il y a une condition de concurrence (exacerbée par des scripts / commandes shell qui traversent des répertoires comme find ) où le verrou échoue et la base de données est écrasée.

La bonne façon de corriger est soit:

1. Corrigez le verrouillage du fichier pour être sûr de la condition de concurrence.
2. Passez d'un format de base de données à un journal d'ajout uniquement (comme .bash_history , .zsh_history , etc.), et ne calculez les poids que lorsque quelqu'un invoque le saut automatique pour changer de répertoire (aka j ).

Hmm, je viens de regarder le code et je ne vois aucun verrouillage réel.
De plus, la sauvegarde est effectuée juste après le passage du fichier temporaire à la vraie base de données, donc si le déplacement échoue (il n'y a pas de vérification d'erreur), nous sauvegardons un fichier vide.

Je suppose qu'améliorer cela ne devrait pas être si difficile.

Peut-être que # 383 n'a pas gardé tous les endroits avec flock , mais il y a une approche plus simple, mais simplement envelopper le tout autojump dans flock , comme:
alias autojump='flock /tmp/autojump.lock autojump'

@trou pouvez-vous tester cela?

_UPD: correction du problème de syntaxe_

Je viens de l'ajouter à mon bashrc, on verra.

Cela ne semble pas aider :(

Hm, comment cela peut-il arriver?
La machine s'est-elle éteinte anormalement (par exemple via le bouton d'alimentation)?

Peut-être aussi autojump appelé depuis sh (au lieu de bash ) dans
parallèle? Puisque dans ce cas l'alias bash ne fonctionnera pas, et dans ce cas vous
peut essayer en l'enveloppant via un script, quelque chose comme:
mv /usr/bin/autojump{,.orig}
echo "flock /tmp/autojump.lock autojump.orig"> / usr / bin / autojump

Ou je rate complètement quelque chose.

Je ne sais pas mais le problème devrait être résolu dans le code de toute façon.

J'utilise l'autojump depuis environ un an maintenant, et soudainement - on dirait que cela a nettoyé toute l'histoire. En regardant ~ / .local / share / autojump, je vois qu'un nouveau fichier a été créé. J'ai vu https://github.com/wting/autojump/issues/208 , qui pointe ici. J'utilise:
autojump-22.3.2-1.fc24.noarch

Y a-t-il d'autres informations de débogage que je peux fournir?

J'ai aussi cela régulièrement, y a-t-il un moyen de déboguer cela?

@wting : Vous avez mentionné qu'une façon de résoudre le problème pourrait être de passer à un "ajouter uniquement le journal" et de calculer les poids lorsque le saut automatique est exécuté.

Je suppose que vous évitez cette solution car le journal peut devenir excessivement long avec le temps. (Et, aussi, parce que ce serait bien si le système existant fonctionnait comme nous le pensons.)

Mais peut-être une solution hybride est-elle possible? Ajoutez des entrées à un journal, mais ajoutez une commande de saut automatique qui les convertit au format de base de données. Lorsque le saut automatique est exécuté, consultez le journal et la base de données pour calculer les poids réels.

Le principal inconvénient est que l'utilisateur doit réduire manuellement la base de données. Une solution consiste à effectuer un test aléatoire chaque fois que le saut automatique est exécuté pour déterminer si la base de données doit être réduite. Cela réduirait au moins les chances d'une condition de course.

@azat : Je vais essayer votre solution.

Depuis que j'ai implémenté un patch proposé en # 482, je n'ai pas rencontré ce bug.

Cependant, je suis également intéressé à entendre les résultats de @ r-barnes. En cas de succès, y a-t-il une raison pour laquelle ce "verrouillage précoce" ne pourrait pas être utilisé en saut automatique?

Argh! Vous avez une mise à jour qui a remplacé le correctif de # 482. Cela s'est produit au prochain redémarrage. Je ne comprends pas comment les autres ne vivent pas cela. Cela m'arrive constamment.

Je n'ai pas eu 100% de succès avec # 482. La base de données semble toujours s'effacer ou, peut-être, est de taille limitée. Cela ne semble pas dépasser 23 entrées pour moi.

J'ai eu 100% de succès avec # 482. Du 21 avril au 25 juillet. J'ai 279 entrées actuellement. Cela suggère que nos situations sont différentes, ce qui signifie qu'il existe plusieurs déclencheurs pour ce bogue. Tout ce que je fais qui le cause, est toujours lié aux différents systèmes de fichiers qu'autojump utilise pour gérer la base de données, comme @Frefreak l'a suggéré. Et, comme je l'ai suggéré, il pourrait y avoir plusieurs chemins de code qui mènent au même bogue, dont certains, je n'utilise jamais mais vous le faites.

Ah, c'est arrivé à nouveau un jour la semaine dernière, après si longtemps depuis la dernière fois.349 entrées ont été supprimées, la taille du fichier est passée de 93K à 77K.

les mises à jour?

J'ai fini par développer ma solution (zsh uniquement). Beaucoup plus petit, plus utile et plus fiable :)
https://github.com/kurkale6ka/zsh (le README sur ce lien)

On dirait que voici plusieurs alternatives existantes. J'essaye maintenant 'fasd' https://github.com/clvv/fasd , qui n'en est qu'un.

Voir https://github.com/rupa/z/issues/198 - rapport de bogue similaire dans un autre projet qui a un problème similaire.
Je ne trouve pas de solution de type autojump qui fonctionne :(

Pour info, je n'ai pas eu ce problème depuis plus d'un an après avoir changé le fichier temporaire dans le même répertoire que le fichier de données. Le patch est:

--- 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()

Le déplacement de fichiers entre les périphériques n'est pas atomique (il effectue une opération de copie + suppression), ils doivent donc être placés dans le même périphérique pour être écrasés de manière atomique.

Cela a beaucoup de sens pour moi. Un mouvement n'est atomique que s'il est sur la même partition ...

Ceci est implémenté dans la v22.5.2 ici: https://github.com/wting/autojump/commit/bc4ea615462adb15ce53de94a09cec30bcc5dc0a

Pour l'instant, veuillez installer et tester à partir de la source et signaler si des données sont toujours perdues.

Je trouve qu'en fait j'ai ouvert une pull request # 495 avec le changement l'année dernière, mais cela est passé inaperçu.

Oups, j'ai rétabli https://github.com/wting/autojump/commit/bc4ea615462adb15ce53de94a09cec30bcc5dc0a et fusionné vos modifications dans https://github.com/wting/autojump/commit/8fffbad95ac5626f4d9338808276ba.

Je ne sais pas si le temps est suffisant pour les tests, mais je n'ai pas de problèmes avec l'effacement de la base de données. Que pensez-vous @wting. Et si cela vous convient, pouvez-vous créer une nouvelle version pour que les distributions puissent être récupérées?

J'ai commencé à souffrir de ce problème d'essuyage. Après plusieurs heures, autojump.txt est effacé. Quoi qu'il en soit pour le déboguer?

J'ai récemment remarqué que le saut automatique ne fonctionnait pas comme prévu. Ensuite, j'ai vérifié pour trouver:

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

Euh ... il semble avoir été réinitialisé. Des idées POURQUOI?

Il y avait une condition de concurrence qui effaçait parfois l'entrée de base de données corrigée dans la v22.5.3.

@minjang , @kaihendry : Pouvez-vous tous exécuter autojump -v et partager le numéro de version indiqué? Si elle est inférieure à cette version, veuillez mettre à niveau et / ou installer à partir de la source.

[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

Je suis un utilisateur d'Archlinux btw: rofl:

Dans 18.04.2 LTS, j'ai la v22.5.1. Je ne sais pas si la mise à jour a été effectuée dans les dépôts Debian / Ubuntu, ou si la version a été gelée. Mise à jour installée: on verra comment ça se passe! (Merci beaucoup.)

Je ne suis pas sûr de savoir qui gère le paquet Debian pour le saut automatique ces jours-ci, mais il est possible qu'ils ne construisent que des balises stables. Alors que la branche principale est sur la v22.5.3 depuis plus de 6 mois, je n'ai tagué que la v22.5.3 ce soir.

Votre meilleur pari pour faire face à cette perte de données aléatoire est d'installer à partir de la source en suivant ces instructions .