Autojump: Entri database dihapus secara teratur

Hai,

Masalah yang sama di sini kecuali saya pikir itu hanya terjadi setelah reboot.

Mungkin diperbaiki oleh https://github.com/wting/autojump/pull/383

Ternyata belum diperbaiki. Ini sangat menyebalkan. Ada ide ?

Maaf atas tanggapan yang terlambat tetapi saya memiliki gambaran kasar tentang apa yang terjadi dan bagaimana cara memperbaikinya.

Pada setiap perubahan direktori autojump mengunci file data dan memperbarui entri, disimpan dalam format seperti "database". Ada kondisi balapan (diperburuk oleh skrip / perintah shell yang melintasi direktori seperti find ) di mana kunci gagal dan db ditimpa.

Cara yang tepat untuk memperbaikinya adalah:

1. Perbaiki penguncian file agar kondisi balapan aman.
2. Beralih dari database seperti format ke log hanya menambahkan (seperti .bash_history , .zsh_history , dll), dan hanya menghitung bobot ketika seseorang memanggil autojump untuk beralih direktori (alias j ).

Hmm, saya baru saja melihat kodenya dan saya tidak melihat adanya penguncian yang sebenarnya.
Selain itu, pencadangan dilakukan tepat setelah pemindahan dari file temp ke DB asli, jadi jika pemindahan gagal (tidak ada pemeriksaan kesalahan), kami mencadangkan file kosong.

Saya kira meningkatkan ini seharusnya tidak sesulit itu.

Mungkin # 383 tidak menjaga semua tempat dengan flock , tetapi ada pendekatan yang lebih sederhana, tetapi hanya membungkus seluruh autojump di dalam flock , seperti:
alias autojump='flock /tmp/autojump.lock autojump'

@trou bisakah kamu menguji ini?

_UPD: perbaiki masalah sintaks_

Saya baru saja menambahkannya ke bashrc saya, kita akan lihat.

Sepertinya tidak membantu :(

Hm, bagaimana ini bisa terjadi?
Apakah mesin Anda mati secara tidak normal (yaitu melalui tombol daya)?

Juga mungkin autojump dipanggil dari sh (bukan bash ) di
paralel? Karena dalam kasus ini alias bash tidak akan berfungsi, dan dalam hal ini Anda
dapat mencoba dengan membungkusnya melalui skrip, seperti:
mv /usr/bin/autojump{,.orig}
echo "flock /tmp/autojump.lock autojump.orig"> / usr / bin / autojump

Atau aku benar-benar kehilangan sesuatu.

Saya tidak tahu tetapi masalahnya harus diperbaiki dalam kode.

Saya telah menggunakan autojump selama sekitar satu tahun sekarang, dan tiba-tiba - sepertinya itu membersihkan seluruh sejarah. Melihat ~ / .local / share / autojump, saya melihat file baru telah dibuat. Saya melihat https://github.com/wting/autojump/issues/208 , yang mengarah ke sini. Saya menggunakan:
autojump-22.3.2-1.fc24.noarch

Info debugging lainnya yang bisa saya berikan?

Saya juga memiliki ini secara teratur, apakah ada cara untuk men-debug ini?

@wting : Anda menyebutkan bahwa salah satu cara untuk menyelesaikan masalah mungkin dengan beralih ke "hanya menambahkan log" dan menghitung bobot saat autojump dijalankan.

Saya kira Anda menghindari solusi ini karena log mungkin menjadi sangat lama dari waktu ke waktu. (Dan, juga, karena alangkah baiknya jika sistem yang ada bekerja dengan cara yang kita kira seharusnya.)

Tapi mungkin solusi hybrid mungkin? Tambahkan entri ke log, tetapi tambahkan perintah autojump yang mengubahnya menjadi format database. Saat autojump dijalankan, lihat log dan database untuk menghitung bobot sebenarnya.

Kelemahan utama dari hal ini adalah pengguna harus menciutkan database secara manual. Solusinya adalah melakukan uji acak setiap kali autojump dijalankan untuk menentukan apakah db harus diciutkan. Ini akan, setidaknya, mengurangi kemungkinan kondisi balapan.

@azat : Saya akan mencoba solusi Anda.

Sejak saya menerapkan tambalan yang diusulkan di # 482, saya tidak mengalami bug ini.

Saya juga tertarik untuk mendengar hasil @ r-barnes. Jika berhasil, adakah alasan "penguncian awal" ini tidak dapat digunakan di autojump?

Argh! Mendapat pembaruan yang menimpa tambalan dari # 482. Itu terjadi pada reboot berikutnya. Saya tidak mengerti bagaimana orang lain tidak mengalami ini. Itu terjadi pada saya terus-menerus.

Saya tidak berhasil 100% dengan # 482. Basis data tampaknya masih bersih atau, mungkin, ukurannya terbatas. Tampaknya tidak tumbuh lebih dari 23 entri untuk saya.

Saya berhasil 100% dengan # 482. 21 April hingga 25 Juli. Saat ini saya memiliki 279 entri. Ini menunjukkan bahwa situasi kami berbeda, yang berarti ada banyak pemicu untuk bug ini. Apa pun yang saya lakukan yang menyebabkannya, selalu terkait dengan sistem file berbeda yang digunakan autojump untuk mengelola db, seperti yang disarankan @Frefreak . Dan, seperti yang saya sarankan, mungkin ada beberapa jalur kode yang mengarah ke bug yang sama, beberapa di antaranya, saya tidak pernah menggunakan tetapi Anda melakukannya.

Ah, itu terjadi lagi suatu hari minggu lalu, setelah sekian lama sejak terakhir kali. 349 entri dihapus, ukuran file menyusut dari 93K menjadi 77K.

ada pembaruan?

Saya akhirnya mengembangkan solusi saya (hanya zsh). Jauh lebih kecil, lebih berguna dan lebih dapat diandalkan :)
https://github.com/kurkale6ka/zsh (README di tautan itu)

Sepertinya di sini ada beberapa alternatif yang ada. Saya mencoba 'fasd' sekarang https://github.com/clvv/fasd , yang hanya satu.

Lihat https://github.com/rupa/z/issues/198 - laporan bug serupa di proyek lain yang memiliki masalah serupa.
Saya tidak dapat menemukan solusi seperti autojump yang berfungsi :(

FYI, saya tidak mengalami masalah ini selama lebih dari satu tahun setelah saya mengubah file sementara ke direktori yang sama dengan file data. Tambalannya adalah:

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

Memindahkan file antar perangkat tidak bersifat atomic (ini melakukan operasi salin + hapus) sehingga file harus diletakkan di perangkat yang sama untuk menimpa secara atomik.

Itu sangat masuk akal bagi saya. Sebuah langkah hanya atom jika berada di partisi yang sama ...

Ini diterapkan di v22.5.2 di sini: https://github.com/wting/autojump/commit/bc4ea615462adb15ce53de94a09cec30bcc5dc0a

Untuk saat ini silahkan install dan uji dari sumber dan laporkan kembali jika data masih hilang.

Saya menemukan bahwa sebenarnya saya membuka permintaan tarik # 495 dengan perubahan tahun lalu, tetapi tidak diperhatikan.

Ups, saya mengembalikan https://github.com/wting/autojump/commit/bc4ea615462adb15ce53de94a09cec30bcc5dc0a dan menggabungkan perubahan Anda menjadi https://github.com/wting/autojump/commit/8fffbad95ac5626f4d9688276ba8a36808c433e3

Saya tidak yakin apakah waktunya cukup untuk pengujian, tetapi saya tidak menemukan masalah dengan penghapusan database. Bagaimana menurut Anda @wting. Dan jika itu tepat untuk Anda, dapatkah Anda membuat rilis baru, sehingga distro dapat mengambilnya?

Saya mulai menderita masalah menyeka ini. Setelah beberapa jam, autojump.txt dihapus. Pokoknya untuk men-debugnya?

Saya baru-baru ini melihat autojump gagal berfungsi seperti yang diharapkan. Kemudian saya memeriksa untuk menemukan:

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

Er ... sepertinya sudah disetel ulang. Ada ide MENGAPA?

Ada kondisi balapan yang terkadang menghapus entri database yang diperbaiki di v22.5.3.

@minjang , @kaihendry : Dapatkah kalian menjalankan autojump -v dan membagikan nomor versi yang terdaftar? Jika kurang dari versi itu, harap tingkatkan dan / atau instal dari sumber.

[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

Saya pengguna Archlinux btw: rofl:

Di 18.04.2 LTS, saya memiliki v22.5.1. Saya tidak yakin apakah pembaruan telah berhasil ke repo Debian / Ubuntu, atau apakah versinya telah dibekukan. Pembaruan yang diinstal: kita akan melihat bagaimana kelanjutannya! (Terima kasih banyak.)

Saya tidak yakin siapa yang memelihara paket Debian untuk autojump hari ini, tapi mungkin mereka hanya membuat tag yang stabil. Sementara cabang master telah berada di v22.5.3 selama> 6 bulan, saya hanya memberi tag v22.5.3 malam ini.

Taruhan terbaik Anda untuk mengatasi kehilangan data acak ini adalah menginstal dari sumber dengan mengikuti petunjuk ini.