Autojump: 정기적으로 삭제되는 데이터베이스 항목

안녕하세요,

재부팅 후에 만 ​​발생한다고 생각하는 것을 제외하고는 동일한 문제입니다.

아마 https://github.com/wting/autojump/pull/383에 의해 수정되었을 것입니다.

분명히 수정되지 않았습니다. 이것은 정말 성가신 일입니다. 어떤 생각?

답변이 늦어서 죄송 합니다만 무슨 일이 일어나고 있는지, 어떻게 해결해야하는지 대략적으로 알고 있습니다.

모든 디렉토리 변경에서 자동 점프는 데이터 파일을 잠그고 "데이터베이스"와 같은 형식으로 저장된 항목을 업데이트합니다. 잠금이 실패하고 db를 덮어 쓰는 경합 조건 ( find 과 같은 디렉토리를 통과하는 쉘 스크립트 / 명령에 의해 악화됨)이 있습니다.

수정하는 적절한 방법은 다음 중 하나입니다.

1. 경쟁 조건이 안전하도록 파일 잠금을 수정하십시오.
2. 데이터베이스와 같은 형식에서 추가 전용 로그 (예 .bash_history , .zsh_history 등)로 전환하고 누군가 자동 점프를 호출하여 디렉토리를 전환 할 때만 가중치를 계산합니다 (일명 j ).

흠 나는 방금 코드를 보았고 실제 잠금이 진행되는 것을 보지 못했습니다.
또한 임시 파일에서 실제 DB로 이동 한 직후에 백업이 이루어 지므로 이동이 실패하면 (오류 확인 없음) 빈 파일을 백업합니다.

나는 이것을 개선하는 것이 그렇게 어렵지 않을 것이라고 생각합니다.

아마도 # 383이 flock 모든 장소를 보호하지는 않았지만 더 간단한 접근 방식이 있지만 autojump 안에 flock autojump 전체를 감싸는 것뿐입니다.
alias autojump='flock /tmp/autojump.lock autojump'

@trou 이것을 테스트 할 수 있습니까?

_UPD : 구문 문제 수정 _

방금 bashrc에 추가했습니다.

도움이되지 않는 것 같습니다 :(

흠, 어떻게 이런 일이 일어날 수 있습니까?
기계 전원이 비정상적으로 꺼졌습니까 (즉, 전원 버튼을 통해)?

또한 autojump sh ( bash 대신) 일반 sh 에서
평행? 이 경우 bash 별칭이 작동하지 않으므로이 경우에는
다음과 같이 스크립트를 통해 래핑하여 시도 할 수 있습니다.
mv /usr/bin/autojump{,.orig}
echo "flock /tmp/autojump.lock autojump.orig"> / usr / bin / autojump

아니면 완전히 뭔가를 놓치고 있습니다.

모르겠지만 어쨌든 코드에서 문제를 해결해야합니다.

나는 지금 약 1 년 동안 autojump를 사용하고 있는데 갑자기 전체 기록을 정리 한 것처럼 보입니다. ~ / .local / share / autojump를 보면 새 파일이 생성 된 것을 볼 수 있습니다. 여기를 가리키는 https://github.com/wting/autojump/issues/208을 보았습니다. 나는 사용하고있다 :
autojump-22.3.2-1.fc24.noarch

제공 할 수있는 다른 디버깅 정보가 있습니까?

나는 또한 이것을 정기적으로 디버깅하는 방법이 있습니까?

@wting : 문제를 해결하는 한 가지 방법은 "추가 전용 로그"로 전환하고 자동 점프가 실행될 때 가중치를 계산하는 것입니다.

로그가 시간이 지남에 따라 엄청나게 길어질 수 있으므로이 솔루션을 피하고 있다고 가정합니다. (또한 기존 시스템이 우리가 생각하는 방식으로 작동하면 좋을 것이기 때문입니다.)

그러나 아마도 하이브리드 솔루션이 가능할까요? 로그에 항목을 추가하지만 데이터베이스 형식으로 변환하는 autojump 명령을 추가하십시오. 자동 점프가 실행되면 로그와 데이터베이스를 모두 참조하여 실제 가중치를 계산하십시오.

이것의 가장 큰 단점은 사용자가 데이터베이스를 수동으로 축소해야한다는 것입니다. 해결 방법은 자동 점프가 실행될 때마다 임의의 테스트를 수행하여 db를 축소해야하는지 여부를 결정하는 것입니다. 이것은 적어도 경쟁 조건의 확률을 낮출 것입니다.

@azat : 나는 당신의 해결책을 시도 할 것입니다.

# 482에서 제안한 패치를 구현 한 이후로이 버그를 경험 한 적이 없습니다.

그래도 @ r-barnes 결과를 듣고 싶습니다. 성공하면이 "조기 잠금"을 자동 점프에서 사용할 수없는 이유가 있습니까?

아아! # 482에서 패치를 덮어 쓴 업데이트를 받았습니다. 다음 재부팅에서 발생했습니다. 나는 다른 사람들이 이것을 어떻게 경험하지 않는지 이해하지 못합니다. 그것은 나에게 끊임없이 발생합니다.

저는 # 482로 100 % 성공하지 못했습니다. 데이터베이스는 여전히 지워진 것처럼 보이거나 크기가 제한되어 있습니다. 나에게는 23 개 항목 이상으로 성장하지 않는 것 같습니다.

# 482로 100 % 성공했습니다. 4 월 21 일부터 7 월 25 일까지. 현재 279 개의 항목이 있습니다. 이것은 우리의 상황이 다르다는 것을 의미하며, 이는이 버그에 대한 여러 트리거가 있음을 의미합니다. 그 원인이 무엇이든간에 @Frefreak이 제안한 것처럼

아, 지난주에 다시 일어난 일인데 지난 시간 이후로 오랜만에 349 개의 항목이 삭제되고 파일 크기가 93K에서 77K로 줄었습니다.

업데이트가 있습니까?

내 솔루션을 개발했습니다 (zsh 만 해당). 더 작고, 더 유용하고, 더 신뢰할 수 있습니다. :)
https://github.com/kurkale6ka/zsh (해당 링크의 README)

여기에 여러 기존 대안이있는 것 같습니다. 나는 지금 https://github.com/clvv/fasd 하나 인 'fasd'를 시도하고 있습니다.

https://github.com/rupa/z/issues/198- 유사한 문제가있는 다른 프로젝트의 유사한 버그 보고서를 참조
작동하는 자동 점프와 유사한 솔루션을 찾을 수 없습니다.

참고로 임시 파일을 데이터 파일과 같은 디렉토리로 변경 한 후 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://github.com/wting/autojump/commit/bc4ea615462adb15ce53de94a09cec30bcc5dc0a

지금은 소스에서 설치 및 테스트하고 데이터가 여전히 손실되는 경우 다시보고하십시오.

실제로 작년에 변경 사항으로 풀 요청 # 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 리포지토리에 적용되었는지 또는 버전이 고정되었는지 확실하지 않습니다. 설치된 업데이트 : 어떻게 진행되는지 살펴 보겠습니다! (정말 고마워.)

요즘 누가 autojump 용 데비안 패키지를 유지하고 있는지는 모르겠지만, 안정된 태그 만 빌드했을 가능성이 있습니다. 마스터 브랜치는 6 개월 이상 v22.5.3에 있었지만 오늘 밤에는 v22.5.3에만 태그를 지정했습니다.

이러한 임의의 데이터 손실을 처리하는 가장 좋은 방법은이 지침에 따라 소스에서 설치하는 것입니다.