Autojump: Datenbankeinträge werden regelmäßig gelöscht

Hallo,

Gleiches Problem hier, außer ich denke, dass es erst nach dem Neustart passiert.

Wahrscheinlich behoben durch https://github.com/wting/autojump/pull/383

Anscheinend nicht behoben. Das ist wirklich nervig. Irgendeine Idee ?

Entschuldigen Sie die verspätete Antwort, aber ich habe eine ungefähre Vorstellung davon, was passiert und wie es behoben werden kann.

Bei jedem Verzeichniswechsel sperrt Autojump die Datendatei und aktualisiert einen Eintrag, der in einem "Datenbank" -ähnlichen Format gespeichert ist. Es gibt eine Race-Bedingung (verschärft durch Shell-Skripte / -Befehle, die Verzeichnisse wie find durchlaufen), bei denen die Sperre fehlschlägt und die Datenbank überschrieben wird.

Der richtige Weg, um das Problem zu beheben, ist entweder:

1. Korrigieren Sie die Dateisperrung, um den Rennzustand zu gewährleisten.
2. Wechseln Sie von einem datenbankähnlichen Format zu einem Protokoll nur zum Anhängen (wie .bash_history , .zsh_history usw.) und berechnen Sie die Gewichte nur, wenn jemand den automatischen Sprung aufruft, um Verzeichnisse zu wechseln (auch bekannt als j ).

Hmm, ich habe mir nur den Code angesehen und sehe keine tatsächliche Sperrung.
Darüber hinaus erfolgt die Sicherung direkt nach dem Verschieben von der temporären Datei in die reale Datenbank. Wenn der Verschieben fehlschlägt (es gibt keine Fehlerprüfung), sichern wir eine leere Datei.

Ich denke, dies zu verbessern sollte nicht so schwer sein.

Vielleicht hat # 383 nicht alle Orte mit flock bewacht, aber es gibt einen einfacheren Ansatz, aber nur das ganze autojump in flock , wie:
alias autojump='flock /tmp/autojump.lock autojump'

@trou kannst du das testen?

_UPD: Syntaxproblem behoben_

Ich habe es gerade zu meinem Bashrc hinzugefügt, wir werden sehen.

Es scheint nicht zu helfen :(

Hm, wie kann das passieren?
Haben Sie die Maschine abnormal ausgeschaltet (dh über den Netzschalter)?

Vielleicht wird auch autojump von regulären sh (anstelle von bash ) in angerufen
parallel? Da in diesem Fall der Bash-Alias ​​nicht funktioniert, und in diesem Fall Sie
kann versuchen, indem Sie es per Skript einpacken, so etwas wie:
mv /usr/bin/autojump{,.orig}
echo "flock /tmp/autojump.lock autojump.orig"> / usr / bin / autojump

Oder mir fehlt etwas komplett.

Ich weiß es nicht, aber das Problem sollte trotzdem im Code behoben werden.

Ich benutze Autojump jetzt seit ungefähr einem Jahr und plötzlich - es sieht so aus, als hätte es die gesamte Geschichte bereinigt. Wenn ich mir ~ / .local / share / autojump ansehe, sehe ich, dass eine neue Datei erstellt wurde. Ich habe https://github.com/wting/autojump/issues/208 gesehen , das hier zeigt. Ich benutze:
autojump-22.3.2-1.fc24.noarch

Weitere Debugging-Informationen, die ich bereitstellen kann?

Ich habe dies auch regelmäßig. Gibt es eine Möglichkeit, dies zu debuggen?

@wting : Sie haben erwähnt, dass eine Möglichkeit zur Behebung des Problems darin bestehen könnte, zu einem "Nur Anhängen-Protokoll" zu wechseln und die Gewichte zu berechnen, wenn der automatische Sprung ausgeführt wird.

Ich nehme an, Sie vermeiden diese Lösung, da das Protokoll im Laufe der Zeit möglicherweise unerschwinglich lang wird. (Und auch, weil es schön wäre, wenn das vorhandene System so funktionieren würde, wie wir es uns vorstellen.)

Aber vielleicht ist eine hybride Lösung möglich? Hängen Sie Einträge an ein Protokoll an, fügen Sie jedoch einen Autojump-Befehl hinzu, der sie in das Datenbankformat konvertiert. Wenn der automatische Sprung ausgeführt wird, konsultieren Sie sowohl das Protokoll als auch die Datenbank, um die tatsächlichen Gewichte zu berechnen.

Der größte Nachteil dabei ist, dass der Benutzer die Datenbank manuell reduzieren muss. Eine Problemumgehung wäre, jedes Mal, wenn ein automatischer Sprung ausgeführt wird, einen zufälligen Test durchzuführen, um festzustellen, ob die Datenbank reduziert werden sollte. Dies würde zumindest die Wahrscheinlichkeit einer Rennbedingung verringern.

@azat : Ich werde deine Lösung ausprobieren.

Seit ich einen in # 482 vorgeschlagenen Patch implementiert habe, ist dieser Fehler nicht aufgetreten.

Ich bin aber auch daran interessiert, @ r-barnes Ergebnisse zu hören. Gibt es einen Grund, warum diese "frühe Sperrung" beim automatischen Springen nicht verwendet werden kann, wenn sie erfolgreich ist?

Argh! Ich habe ein Update erhalten, das den Patch von # 482 überschrieben hat. Es geschah beim nächsten Neustart. Ich verstehe nicht, wie andere Leute das nicht erleben. Es passiert mir ständig.

Ich hatte mit # 482 keinen 100% igen Erfolg. Die Datenbank scheint immer noch zu löschen oder ist möglicherweise in der Größe begrenzt. Es scheint für mich nicht viel über 23 Einträge hinaus zu wachsen.

Ich hatte 100% Erfolg mit # 482. 21. April bis 25. Juli. Ich habe derzeit 279 Einträge. Dies deutet darauf hin, dass unsere Situationen unterschiedlich sind, was bedeutet, dass es mehrere Auslöser für diesen Fehler gibt. Was auch immer ich tue, das es verursacht, hängt immer mit den verschiedenen Dateisystemen zusammen, die Autojump verwendet, um die Datenbank zu verwalten, wie @Frefreak vorgeschlagen hat. Und genau wie ich vorgeschlagen habe, könnte es mehrere Codepfade geben, die zu demselben Fehler führen. Einige davon verwende ich nur nie, aber Sie tun es.

Ah, es ist eines Tages letzte Woche wieder passiert, nach so langer Zeit seit dem letzten Mal. 349 Einträge wurden entfernt, die Dateigröße wurde von 93 KB auf 77 KB verringert.

irgendwelche Updates?

Am Ende habe ich meine Lösung entwickelt (nur zsh). Viel kleiner, nützlicher und zuverlässiger :)
https://github.com/kurkale6ka/zsh (die README-Datei zu diesem Link)

Es sieht so aus, als ob hier mehrere Alternativen vorhanden sind. Ich versuche jetzt 'fasd' https://github.com/clvv/fasd , was nur eines ist.

Siehe https://github.com/rupa/z/issues/198 - ähnlicher Fehlerbericht in einem anderen Projekt mit einem ähnlichen Problem.
Ich kann keine funktionierende Autojump-ähnliche Lösung finden :(

Zu Ihrer Information, ich hatte dieses Problem seit mehr als einem Jahr nicht mehr, nachdem ich die temporäre Datei in dasselbe Verzeichnis wie die Datendatei geändert habe. Der Patch ist:

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

Das Verschieben von Dateien zwischen Geräten ist nicht atomar (es führt einen Kopier- / Löschvorgang aus), daher sollten sie zum atomaren Überschreiben auf demselben Gerät abgelegt werden.

Das macht für mich sehr viel Sinn. Ein Zug ist nur dann atomar, wenn er sich auf derselben Partition befindet ...

Dies ist in Version 22.5.2 hier implementiert: https://github.com/wting/autojump/commit/bc4ea615462adb15ce53de94a09cec30bcc5dc0a

Fürs Erste installieren und testen Sie bitte von der Quelle und melden Sie zurück, wenn noch Daten verloren gehen.

Ich finde, dass ich letztes Jahr mit der Änderung eine Pull-Anfrage Nr. 495 eröffnet habe, die aber unbemerkt blieb.

Hoppla, ich habe https://github.com/wting/autojump/commit/bc4ea615462adb15ce53de94a09cec30bcc5dc0a zurückgesetzt und Ihre Änderungen in https://github.com/wting/autojump/commit/8fffbad95ac562688888888888888888888

Ich bin nicht sicher, ob die Zeit zum Testen ausreicht, aber ich habe keine Probleme beim Löschen der Datenbank. Was denkst du @wting. Und wenn es für Sie richtig ist, können Sie eine neue Version erstellen, damit die Distributionen sie aufnehmen können?

Ich begann unter diesem Wischproblem zu leiden. Nach einigen Stunden wird autojump.txt ausgelöscht. Wie auch immer, um es zu debuggen?

Ich habe kürzlich festgestellt, dass der automatische Sprung nicht wie erwartet funktioniert. Dann habe ich nachgesehen:

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

Äh ... es scheint zurückgesetzt worden zu sein. Irgendwelche Ideen WARUM?

Es gab eine Race-Bedingung, die gelegentlich den in v22.5.3 behobenen Datenbankeintrag löschte.

@minjang , @kaihendry : Kannst du autojump -v ausführen und die aufgelistete Versionsnummer teilen? Wenn es weniger als diese Version ist, aktualisieren und / oder installieren Sie es bitte von der Quelle.

[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

Ich bin ein Archlinux-Benutzer übrigens: rofl:

In 18.04.2 LTS habe ich v22.5.1. Ich bin nicht sicher, ob das Update es in die Debian / Ubuntu-Repos geschafft hat oder ob die Version eingefroren wurde. Installiertes Update: Wir werden sehen, wie es geht! (Vielen Dank.)

Ich bin mir nicht sicher, wer das Debian-Paket für Autojump in diesen Tagen verwaltet, aber es ist möglich, dass sie nur stabile Tags aufbauen. Während der Hauptzweig seit> 6 Monaten auf v22.5.3 ist, habe ich heute Abend nur v22.5.3 getaggt.

Um mit diesem zufälligen Datenverlust fertig zu werden, installieren Sie am besten von der Quelle aus, indem Sie diese Anweisungen befolgen .