Autojump: تم مسح إدخال (إدخالات) قاعدة البيانات بانتظام

أهلا،

نفس المشكلة هنا إلا أنني أعتقد أنها تحدث فقط بعد إعادة التشغيل.

ربما تم إصلاحه بواسطة https://github.com/wting/autojump/pull/383

على ما يبدو لم يتم إصلاحه. هذا حقا مزعج اي فكرة ؟

آسف على الرد المتأخر ولكن لدي فكرة تقريبية عما يحدث وكيفية إصلاحه.

في كل قفزة تلقائية لتغيير الدليل ، يقفل ملف البيانات ويحدّث إدخالاً مخزّنًا في "قاعدة بيانات" مثل التنسيق. هناك حالة سباق (تتفاقم بسبب نصوص / أوامر shell التي تعبر الدلائل مثل find ) حيث يفشل القفل ويتم الكتابة فوق db.

الطريقة الصحيحة للإصلاح هي إما:

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}
صدى "flock /tmp/autojump.lock autojump.orig"> / usr / bin / autojump

أو أفتقد شيئًا تمامًا.

لا أعرف ولكن يجب إصلاح المشكلة في الكود على أي حال.

لقد كنت أستخدم autojump لمدة عام تقريبًا الآن ، وفجأة - يبدو أنه قد تم تنظيف السجل بالكامل. بالنظر إلى ~ / .local / share / autojump ، أرى أنه تم إنشاء ملف جديد. رأيت https://github.com/wting/autojump/issues/208 ، والتي تشير هنا. أنا استخدم:
autojump-22.3.2-1.fc24.noarch

أي معلومات تصحيح أخطاء أخرى يمكنني تقديمها؟

لدي أيضًا هذا بانتظام ، هل هناك طريقة لتصحيح هذا؟

wting : لقد ذكرت أن إحدى طرق حل المشكلة قد تكون التبديل إلى "سجل الإلحاق فقط" وحساب الأوزان عند تشغيل القفز التلقائي.

أفترض أنك تتجنب هذا الحل لأن السجل قد يصبح طويلاً مع مرور الوقت. (وأيضًا ، لأنه سيكون من الجيد أن يعمل النظام الحالي بالطريقة التي نعتقد أنها يجب أن تعمل.)

لكن ربما يكون الحل المختلط ممكنًا؟ إلحاق إدخالات بسجل ، لكن أضف أمرًا للقفز التلقائي يحولها إلى تنسيق قاعدة البيانات. عند تشغيل القفز التلقائي ، استشر كلاً من السجل وقاعدة البيانات لحساب الأوزان الفعلية.

الجانب السلبي قبل كل شيء هو أنه يتطلب من المستخدم طي قاعدة البيانات يدويًا. قد يتمثل الحل في إجراء اختبار عشوائي في كل مرة يتم فيها تشغيل القفز التلقائي لتحديد ما إذا كان يجب تصغير db. هذا من شأنه ، على الأقل ، تقليل احتمالات حالة السباق.

azat : سأقوم بتجربة الحل الخاص بك.

منذ أن قمت بتنفيذ التصحيح المقترح في # 482 ، لم أواجه هذا الخطأ.

أنا مهتم أيضًا بسماع نتائج @ r-barnes. إذا نجحت ، فهل هناك سبب لعدم إمكانية استخدام "القفل المبكر" في القفزة التلقائية؟

أرغ! حصلت على تحديث قام بالكتابة فوق التصحيح من # 482. حدث ذلك في إعادة التشغيل التالية. لا أفهم كيف لا يعاني الآخرون من ذلك. يحدث لي باستمرار.

لم أحقق نجاحًا بنسبة 100٪ مع # 482. لا تزال قاعدة البيانات تبدو واضحة ، أو ربما تكون محدودة الحجم. لا يبدو أنه يتعدى 23 إدخالاً بالنسبة لي.

لقد حققت نجاحًا بنسبة 100 ٪ مع # 482. 21 أبريل حتى 25 يوليو. لدي 279 مدخلًا حاليًا. يشير هذا إلى أن مواقفنا مختلفة ، مما يعني أن هناك عدة مسببات لهذا الخطأ. كل ما أفعله يسبب ذلك ، فهو مرتبط دائمًا بأنظمة الملفات المختلفة التي يستخدمها autojump لإدارة db ، مثل Frefreak الذي اقترحه. ومثلما اقترحت ، يمكن أن يكون هناك العديد من مسارات الشفرة التي تؤدي إلى نفس الخطأ ، وبعضها لا أستخدمه أبدًا ولكنك تستخدمه.

آه ، لقد حدث ذلك مرة أخرى يومًا ما الأسبوع الماضي ، بعد وقت طويل منذ آخر مرة تمت إزالة 349 إدخالًا ، وتقلص حجم الملف من 93 ألفًا إلى 77 ألفًا.

أي تحديثات؟

لقد انتهيت من تطوير الحل الخاص بي (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://github.com/wting/autojump/commit/bc4ea615462adb15ce53de94a09cec30bcc5dc0a

في الوقت الحالي ، يرجى التثبيت والاختبار من المصدر والإبلاغ مرة أخرى في حالة استمرار فقد البيانات.

أجد أنني فتحت بالفعل طلب سحب رقم 495 مع التغيير العام الماضي ، لكنه لم يلاحظه أحد.

عفوًا ، عدت إلى https://github.com/wting/autojump/commit/bc4ea615462adb15ce53de94a09cec30bcc5dc0a ودمجت تغييراتك في https://github.com/wting/autojump/commit/8fffbad95ac5626f4d9688276ba8a33808.

لست متأكدًا مما إذا كان الوقت كافيًا للاختبار ، ولكن لم يتم العثور على مشكلات في مسح قاعدة البيانات. ما رأيك @ 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 ، أو ما إذا كان الإصدار قد تم تجميده. التحديث المثبت: سنرى كيف ستسير الامور! (شكرا جزيلا.)

لست متأكدًا من الذي يحتفظ بحزمة دبيان للقفز التلقائي هذه الأيام ، لكن من المحتمل أنهم ينشئون فقط علامات ثابتة. بينما كان الإصدار الرئيسي في الإصدار 22.5.3 لمدة تزيد عن 6 أشهر ، قمت فقط بوضع علامة على الإصدار 22.5.3 الليلة.

أفضل رهان للتعامل مع هذا الفقد العشوائي للبيانات هو التثبيت من المصدر باتباع هذه التعليمات .