Autojump: 定期清除数据库条目

你好，

除了我认为它仅在重新启动后才会发生，这里也存在同样的问题。

可能是由https://github.com/wting/autojump/pull/383修复的

显然不是固定的。 真烦人。 任何想法 ？

对不起，您的回复很晚，但是我对正在发生的事情以及如何解决它有一个大概的了解。

在每个目录更改上，自动跳转都会锁定数据文件并更新以“数据库”之类的格式存储的条目。 有一个竞争条件（遍历find类的目录的shell脚本/命令加剧了），其中锁失败并且数据库被覆盖。

正确的解决方法是：

1. 修复文件锁定以确保竞态条件安全。
2. 从格式之类的数据库切换到仅追加日志（例如.bash_history ， .zsh_history等），并且仅当有人调用自动跳转来切换目录时才计算权重（也就是j ）。

嗯，我只是看了一下代码，却没有看到任何实际的锁定。
此外，备份是在从临时文件移至实际数据库之后立即完成的，因此，如果移动失败（没有错误检查），我们将备份一个空文件。

我想改善这一点不应该那么难。

也许＃383并没有使用flock保护所有地方，但是有一种更简单的方法，只是将整个autojump包裹在flock ，例如：
alias autojump='flock /tmp/autojump.lock autojump'

@trou可以测试一下吗？

_UPD：修复语法问题_

我刚刚将其添加到我的bashrc中，我们将看到。

它似乎没有帮助:(

嗯，这怎么可能发生？
您的机器电源是否异常关闭（即通过电源按钮）？

也可能从常规sh （而不是bash ）中调用autojump
平行？ 由于在这种情况下bash别名不起作用，因此在这种情况下，您
可以尝试通过脚本将其包装起来，例如：
mv /usr/bin/autojump{,.orig}
回声“ flock /tmp/autojump.lock autojump.orig”> / usr / bin / autojump

或我完全缺少了一些东西。

我不知道，但是无论如何该问题应该在代码中解决。

我使用自动跳转已有大约一年的时间，突然间-看起来它清除了整个历史记录。 查看〜/ .local / share / autojump，我看到创建了一个新文件。 我看到了https://github.com/wting/autojump/issues/208 ，它指向此处。 我正在使用：
autojump-22.3.2-1.fc24.noarch

我可以提供其他调试信息吗？

我也经常有这种方法可以调试吗？

@wting ：您提到解决问题的一种方法可能是切换到“仅追加日志”并在运行自动跳转时计算权重。

我想您正在避免此解决方案，因为随着时间的流逝，日志可能会变得过长。 （而且，因为如果现有系统按照我们认为的方式工作，那就太好了。）

但是也许可以使用混合解决方案？ 将条目追加到日志，但是添加自动跳转命令，将其转换为数据库格式。 运行自动跳转时，请同时查阅日志和数据库以计算实际权重。

最主要的缺点是，它要求用户手动折叠数据库。 解决方法是，每次运行自动跳转时都进行一次随机测试，以确定是否应折叠数据库。 至少，这将降低比赛条件的几率。

@azat ：我将尝试您的解决方案。

自从我实现了＃482中提出的补丁以来，我还没有遇到过这个错误。

我也有兴趣听到@ r-barnes的结果。 如果成功，是否有原因不能在自动跳转中使用此“早期锁定”？

啊！ 获得了覆盖＃482补丁的更新。 它在下次重新启动时发生。 我不明白其他人没有这种经历。 它经常发生在我身上。

我没有＃482的100％成功。 数据库似乎仍然很清晰，或者大小可能有限。 对于我来说，它似乎增长不超过23个条目。

＃482我确实取得了100％的成功。 4月21日至7月25日。我目前有279个条目。 这表明我们的情况有所不同，这意味着此错误有多个触发器。 无论我做什么导致它，总是与自动跳转用来管理数据库的不同文件系统有关，例如

嗯，上周的某天又发生了一次，距上次这么长时间以来。349个条目被删除，文件大小从93K缩小到77K。

任何更新？

我最终开发了解决方案（仅zsh）。 体积更小，更有用，更可靠:)
https://github.com/kurkale6ka/zsh （该链接上的自述文件）

看起来这里是几个现有的替代方案。 我现在正在尝试“ fasd” https://github.com/clvv/fasd ，这只是一个。

参见https://github.com/rupa/z/issues/198-另一个存在类似问题的项目中的类似错误报告。
我找不到工作autojump样的解决方案:(

仅供参考，将临时文件更改为与数据文件相同的目录后，一年多没有出现此问题。 补丁是：

--- 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用户btw：rofl：

在18.04.2 LTS中，我有v22.5.1。 我不确定是否已将其更新到Debian / Ubuntu存储库，或者版本是否已冻结。 已安装的更新：我们将看看进展如何！ （非常感谢。）

我不确定这几天谁会维护Debian软件包来进行自动跳转，但是可能他们只是建立了稳定的标签。 虽然master分支已在v22.5.3上运行了6个月以上，但我今晚只标记了v22.5.3。

解决这种随机数据丢失的最佳选择是按照以下说明从源代码进行安装。