Autojump: Записи в базе данных регулярно стираются

Привет,

Здесь та же проблема, но я думаю, что это происходит только после перезагрузки.

Вероятно, исправлено https://github.com/wting/autojump/pull/383

Видимо не исправлено. Это действительно раздражает. Любая идея ?

Приносим извинения за поздний ответ, но у меня есть приблизительное представление о том, что происходит и как это исправить.

При каждом изменении каталога автопереход блокирует файл данных и обновляет запись, хранящуюся в формате, подобном «базе данных». Существует состояние гонки (усугубляемое сценариями / командами оболочки, которые перемещаются по каталогам, например find ), когда блокировка не выполняется, а база данных перезаписывается.

Правильный способ исправить:

1. Исправьте блокировку файла, чтобы обеспечить безопасность в условиях гонки.
2. Переключитесь с формата, подобного базе данных, на журнал только с добавлением (например, .bash_history , .zsh_history и т. Д.) И вычисляйте веса только тогда, когда кто-то вызывает автопереход для переключения каталогов (также известный как j ).

Хм, я только что посмотрел на код и не заметил, как происходит блокировка.
Более того, резервное копирование выполняется сразу после перехода из временного файла в реальную БД, поэтому, если перемещение не удалось (нет проверки ошибок), мы создаем резервную копию пустого файла.

Думаю, улучшить это не должно быть так сложно.

Возможно, # 383 не охранял все места с помощью flock , но есть более простой подход, а просто обертывание всего autojump внутри flock , например:
alias autojump='flock /tmp/autojump.lock autojump'

@trou ты можешь это проверить?

_UPD: исправить проблему с синтаксисом_

Я только что добавил в свой bashrc, посмотрим.

Кажется, это не помогает :(

Хм, как это может случиться?
Устройство отключилось ненормально (например, с помощью кнопки питания)?

Также, возможно, autojump вызывается из обычного sh (вместо bash ) в
параллельно? Поскольку в этом случае псевдоним bash не будет работать, и в этом случае вы
можно попробовать обернуть его через скрипт, например:
mv /usr/bin/autojump{,.orig}
echo "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. Произошло это при следующей перезагрузке. Я не понимаю, как другие люди этого не переживают. Со мной такое случается постоянно.

У меня не было 100% успеха с # 482. База данных все еще кажется чистой или, возможно, имеет ограниченный размер. Мне кажется, что это не намного больше, чем 23 записи.

Я добился 100% успеха с # 482. С 21 апреля по 25 июля. Сейчас у меня 279 работ. Это говорит о том, что у нас разные ситуации, а это значит, что у этой ошибки есть несколько триггеров. Все, что я делаю, что вызывает это, всегда связано с различными файловыми системами, которые autojump использует для управления базой данных , как предложил

Ах, это случилось снова когда-нибудь на прошлой неделе, спустя столько времени, прошедшее с момента последнего удаления 349 записей, размер файла уменьшился с 93 КБ до 77 КБ.

любые обновления?

Я закончил разработку своего решения (только для zsh). Намного меньше, полезнее и надежнее :)
https://github.com/kurkale6ka/zsh (README по этой ссылке)

Похоже, вот несколько существующих альтернатив. Сейчас я пытаюсь выполнить «fasd» https://github.com/clvv/fasd , это всего лишь один.

См. Https://github.com/rupa/z/issues/198 - аналогичный отчет об ошибке в другом проекте с аналогичной проблемой.
Я не могу найти работающее решение, подобное автопрыгу :(

К вашему сведению, у меня не было этой проблемы более года после того, как я изменил временный файл в тот же каталог, что и файл данных. Патч есть:

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

Перемещение файлов между устройствами не является атомарным (выполняется операция копирования + удаления), поэтому их следует помещать на одно и то же устройство для атомарной перезаписи.

Для меня это имеет большой смысл. Ход является атомарным, только если он находится в том же разделе ...

Это реализовано в версии 22.5.2 здесь: https://github.com/wting/autojump/commit/bc4ea615462adb15ce53de94a09cec30bcc5dc0a

А пока, пожалуйста, установите и протестируйте из источника и сообщите, если данные все еще теряются.

Я обнаружил, что на самом деле я открыл пул-реквест № 495 с изменением в прошлом году, но это осталось незамеченным.

К сожалению, я отменил https://github.com/wting/autojump/commit/bc4ea615462adb15ce53de94a09cec30bcc5dc0a и объединил ваши изменения в https://github.com/wting/autojump/commit/8fffbad95ac5626f4d833e3808276.

Не уверен, хватит ли времени на тестирование, но проблем с очисткой базы данных у меня не обнаружено. Как ты думаешь @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 сегодня вечером.

Лучше всего справиться с этой случайной потерей данных - установить из источника, следуя этим инструкциям .