Autojump: データベースエントリは定期的に消去されます

こんにちは、

再起動後にのみ発生すると思うことを除いて、ここでも同じ問題が発生します。

おそらくhttps://github.com/wting/autojump/pull/383によって修正されました

どうやら修正されていません。 これは本当に迷惑です。 何か案が ？

応答が遅れて申し訳ありませんが、何が起こっているのか、そしてそれを修正する方法について大まかな考えがあります。

ディレクトリが変更されるたびに、自動ジャンプによってデータファイルがロックされ、「データベース」のような形式で保存されているエントリが更新されます。 ロックが失敗してデータベースが上書きされる競合状態（ findなどのディレクトリをトラバースするシェルスクリプト/コマンドによって悪化する）があります。

修正する適切な方法は次のいずれかです。

1. 競合状態が安全になるようにファイルロックを修正します。
2. データベースのような形式から追加専用ログ（ .bash_history 、 .zsh_historyなど）に切り替え、誰かが自動ジャンプを呼び出してディレクトリを切り替えるときにのみ重みを計算します（別名j ）。

うーん、コードを見ただけで、実際のロックが行われているのがわかりません。
さらに、バックアップは一時ファイルから実際のDBへの移動の直後に実行されるため、移動が失敗した場合（エラーチェックはありません）、空のファイルをバックアップしています。

これを改善するのはそれほど難しいことではないと思います。

たぶん＃383はflockですべての場所を守っていなかったかもしれませんが、もっと簡単なアプローチがありますが、 flock中にautojump全体をラップするだけです。
alias autojump='flock /tmp/autojump.lock autojump'

@trouこれをテストできますか？

_UPD：構文の問題を修正_

これをbashrcに追加したところです。

それは役に立たないようです:(

うーん、これはどのように起こりますか？
マシンの電源が異常にオフになりましたか（つまり、電源ボタンを使用）？

また、 bash代わりに通常のshから呼び出されたautojump
平行？ この場合、bashエイリアスは機能しないため、この場合は
次のようなスクリプトでラップして試すことができます。
mv / usr / bin / autojump {、。orig}
echo "flock /tmp/autojump.lock autojump.orig"> / usr / bin / autojump

または私は完全に何かが欠けています。

わかりませんが、とにかくコードで問題を修正する必要があります。

オートジャンプを使って約1年になりますが、突然、歴史全体が一掃されたようです。 〜/ .local / share / autojumpを見ると、新しいファイルが作成されたことがわかります。 ここを指すhttps://github.com/wting/autojump/issues/208を見ました。 私が使用しているもの：
autojump-22.3.2-1.fc24.noarch

私が提供できる他のデバッグ情報はありますか？

私もこれを定期的に持っていますこれをデバッグする方法はありますか？

@wting ：問題を解決する1つの方法は、「ログのみを追加」に切り替えて、自動ジャンプの実行時に重みを計算することである可能性があるとおっしゃいました。

ログが時間の経過とともに非常に長くなる可能性があるため、このソリューションを回避していると思います。 （また、既存のシステムが私たちが思っているように機能していればいいのですが。）

しかし、おそらくハイブリッドソリューションは可能ですか？ エントリをログに追加しますが、エントリをデータベース形式に変換する自動ジャンプコマンドを追加します。 自動ジャンプを実行するときは、ログとデータベースの両方を参照して、実際の重みを計算してください。

これの最大の欠点は、ユーザーがデータベースを手動で折りたたむ必要があることです。 回避策は、自動ジャンプが実行されるたびにランダムテストを実行して、データベースを折りたたむ必要があるかどうかを判断することです。 これにより、少なくとも、競合状態の可能性が低くなります。

@azat ：私はあなたの解決策を試すつもりです。

＃482で提案されたパッチを実装して以来、このバグは発生していません。

@ r-barnesの結果も聞きたいです。 成功した場合、この「早期ロック」を自動ジャンプで使用できなかった理由はありますか？

ああ！ ＃482からパッチを上書きするアップデートを入手しました。 次の再起動時に発生しました。 他の人がこれをどのように経験していないのかわかりません。 それは私に絶えず起こります。

＃482では100％成功しませんでした。 データベースはまだクリアされているように見えるか、おそらくサイズが制限されています。 私にとっては23エントリをはるかに超えて成長しているようには見えません。

私は＃482で100％成功しました。 4月21日から7月25日まで。現在279件のエントリーがあります。 これは、状況が異なることを示しています。つまり、このバグには複数のトリガーがあります。 @Frefreakが提案したように、私がそれを引き起こしていることは何でも、autojumpがデータベースを管理するために使用するさまざまなファイルシステムに常に関連しています。 そして、私が提案したように、同じバグにつながる複数のコードパスが存在する可能性があり、そのうちのいくつかは、私は決して使用しませんが、あなたは使用します。

ああ、それは先週のいつか、前回から久しぶりに再び起こった。349エントリが削除され、ファイルサイズが93Kから77Kに縮小した。

更新はありますか？

私は自分のソリューションを開発することになりました（zshのみ）。 はるかに小さく、より便利で、より信頼性があります:)
https://github.com/kurkale6ka/zsh （そのリンクのREADME）

ここにいくつかの既存の選択肢があるように見えます。 私は今https://github.com/clvv/fasdで「fasd」を試してい

https://github.com/rupa/z/issues/198を参照して
私が働いてautojumpのような解決策を見つけることができません:(

参考までに、一時ファイルをデータファイルと同じディレクトリに変更してから1年以上この問題は発生していません。 パッチは次のとおりです。

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

デバイス間でのファイルの移動はアトミックではないため（コピー+削除操作を実行します）、アトミックに上書きするには、同じデバイスにファイルを配置する必要があります。

それは私には非常に理にかなっています。 移動は、同じパーティション上にある場合にのみアトミックです...

これはv22.5.2でここに実装されています： https ：

今のところ、ソースからインストールしてテストし、データがまだ失われている場合は報告してください。

実際、昨年の変更でプルリクエスト＃495を開いたのですが、気づかれませんでした。

おっと、 https：//github.com/wting/autojump/commit/bc4ea615462adb15ce53de94a09cec30bcc5dc0aを元に戻し、変更をhttps://github.com/wting/autojump/commit/8fffbad95ac5626f4d9688276ba8a36808c433e3にマージしました

テストに十分な時間かどうかはわかりませんが、データベースのワイプで問題は見つかりませんでした。 @wtingはどう思いますか。 そして、それがあなたに適している場合は、新しいリリースを作成して、ディストリビューションがそれを取得できるようにすることはできますか？

私はこの拭き取りの問題に苦しみ始めました。 数時間後、 autojump.txtは消去されます。 とにかくそれをデバッグしますか？

最近、オートジャンプが期待どおりに機能しないことに気づきました。 それから私は見つけるためにチェックしました：

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

えーと…リセットされたようです。 なぜアイデアはありますか？

v22.5.3で修正されたデータベースエントリをときどきワイプする競合状態がありました。

@ minjang 、 @ kaihendry ： autojump -vを実行して、リストされているバージョン番号を共有できますか？ そのバージョンよりも小さい場合は、ソースからアップグレードまたはインストールしてください。

[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

私はArchlinuxユーザーですところで：rofl：

18.04.2 LTSでは、v22.5.1があります。 アップデートがDebian / Ubuntuリポジトリに到達したのか、それともバージョンがフリーズしたのかはわかりません。 インストールされたアップデート：それがどうなるか見ていきます！ （本当にありがとう。）

最近、誰が自動ジャンプ用のDebianパッケージを管理しているかはわかりませんが、安定したタグのみを構築している可能性があります。 マスターブランチはv22.5.3で6か月以上使用されていますが、今夜はv22.5.3にのみタグを付けました。

このランダムなデータ損失に対処する最善の策は、これらの手順に従ってソースからインストールすることです。