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'

@ क्या आप इसका परीक्षण कर सकते हैं?

_UPD: सिंटैक्स समस्या ठीक करें_

मैंने इसे अभी अपने bashrc में जोड़ा है, हम देखेंगे।

ऐसा लगता है कि यह मदद नहीं करता है :(

हम्म, यह कैसे हो सकता है?
क्या आपने मशीन को असामान्य रूप से बंद किया था (अर्थात पावर बटन के माध्यम से)?

इसके अलावा शायद autojump नियमित sh ( bash बजाय) से कॉल किया जाता है
समानांतर? चूंकि इस मामले में बैश उपनाम काम नहीं करेगा, और इस मामले में आप
इसे स्क्रिप्ट के माध्यम से लपेटकर कोशिश कर सकते हैं, जैसे कुछ:
mv /usr/bin/autojump{,.orig}
इको "झुंड /tmp/autojump.lock autojump.orig" > /usr/bin/autojump

या मैं पूरी तरह से कुछ याद कर रहा हूँ।

मुझे नहीं पता लेकिन इस मुद्दे को वैसे भी कोड में तय किया जाना चाहिए।

मैं अब लगभग एक साल से ऑटोजंप का उपयोग कर रहा हूं, और अचानक - ऐसा लगता है कि इसने पूरे इतिहास को साफ कर दिया है। ~/.local/share/autojump को देखते हुए, मुझे लगता है कि एक नई फ़ाइल बनाई गई थी। मैंने https://github.com/wting/autojump/issues/208 देखा, जो यहां इंगित करता है। मैं उपयोग कर रहा हूँ:
ऑटोजंप-22.3.2-1.fc24.noarch

कोई अन्य डिबगिंग जानकारी जो मैं प्रदान कर सकता हूं?

मेरे पास यह नियमित रूप से है क्या इसे डीबग करने का कोई तरीका है?

@wting : आपने उल्लेख किया है कि समस्या को हल करने का एक तरीका "केवल लॉग संलग्न करें" पर स्विच करना और ऑटोजंप चलने पर वजन की गणना करना हो सकता है।

मुझे लगता है कि आप इस समाधान से बच रहे हैं क्योंकि लॉग समय के साथ निषेधात्मक रूप से लंबा हो सकता है। (और, यह भी, क्योंकि यह अच्छा होगा यदि मौजूदा प्रणाली उस तरह से काम करे जिस तरह से हमें लगता है कि इसे करना चाहिए।)

लेकिन शायद एक संकर समाधान संभव है? लॉग में प्रविष्टियां जोड़ें, लेकिन एक ऑटोजंप कमांड जोड़ें जो उन्हें डेटाबेस प्रारूप में परिवर्तित करता है। जब ऑटोजंप चलाया जाता है, तो वास्तविक वजन की गणना करने के लिए लॉग और डेटाबेस दोनों से परामर्श लें।

इसका सबसे महत्वपूर्ण पहलू यह है कि इसके लिए उपयोगकर्ता को डेटाबेस को मैन्युअल रूप से संक्षिप्त करने की आवश्यकता होती है। डीबी को ध्वस्त किया जाना चाहिए या नहीं यह निर्धारित करने के लिए ऑटोजंप चलाने पर हर बार एक यादृच्छिक परीक्षण करना होगा। यह, कम से कम, दौड़ की स्थिति की बाधाओं को कम करेगा।

@azat : मैं आपके समाधान का प्रयास करने जा रहा हूं।

चूंकि मैंने #482 में प्रस्तावित एक पैच लागू किया है, इसलिए मैंने इस बग का अनुभव नहीं किया है।

हालांकि, मुझे @ r-barnes परिणाम सुनने में दिलचस्पी है। यदि सफल हो, तो क्या कोई कारण है कि इस "प्रारंभिक लॉकिंग" का उपयोग ऑटोजंप में नहीं किया जा सकता है?

अर्घ! एक अपडेट मिला जिसने #482 से पैच को ओवरराइट कर दिया। यह अगले रिबूट पर हुआ। मुझे समझ में नहीं आता कि दूसरे लोग इसका अनुभव कैसे नहीं कर रहे हैं। यह मेरे साथ लगातार होता है।

मुझे #४८२ के साथ १००% सफलता नहीं मिली। डेटाबेस अभी भी स्पष्ट प्रतीत होता है या, शायद, आकार में सीमित है। यह मेरे लिए 23 प्रविष्टियों से बहुत आगे नहीं बढ़ता है।

मुझे #४८२ के साथ १००% सफलता मिली। २१ अप्रैल से २५ जुलाई तक। मेरे पास वर्तमान में २७९ प्रविष्टियाँ हैं। इससे पता चलता है कि हमारी स्थितियां अलग हैं, जिसका अर्थ है कि इस बग के लिए कई ट्रिगर हैं। जो कुछ भी मैं कर रहा हूं वह इसका कारण बनता है, हमेशा विभिन्न फाइल सिस्टम से संबंधित होता है जो ऑटोजंप डीबी को प्रबंधित करने के लिए उपयोग करता है, जैसे @ फ्रीफ्रीक ने सुझाव दिया। और, जैसा कि मैंने सुझाव दिया था, कई कोड पथ हो सकते हैं जो एक ही बग की ओर ले जाते हैं, जिनमें से कुछ, मैं कभी उपयोग नहीं करता लेकिन आप करते हैं।

आह, यह पिछले सप्ताह किसी दिन फिर से हुआ, पिछली बार के इतने लंबे समय के बाद। 349 प्रविष्टियाँ हटा दी गईं, फ़ाइल का आकार 93K से 77K तक सिकुड़ गया।

कोई अपडेट्स?

मैंने अपना समाधान विकसित कर लिया है (केवल 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()

डिवाइसों में फ़ाइलें ले जाना परमाणु नहीं है (यह एक कॉपी + डिलीट ऑपरेशन करता है) इसलिए उन्हें परमाणु रूप से ओवरराइट करने के लिए एक ही डिवाइस में रखा जाना चाहिए।

यह मेरे लिए बहुत मायने रखता है। एक चाल केवल परमाणु है यदि यह एक ही विभाजन पर है ...

इसे यहां 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

मैं एक आर्कलिनक्स उपयोगकर्ता बीटीडब्ल्यू हूं: आरओएफएल:

18.04.2 एलटीएस में, मेरे पास v22.5.1 है। मुझे यकीन नहीं है कि अपडेट ने इसे डेबियन/उबंटू रेपो में बना दिया है, या यदि संस्करण जमे हुए हैं। स्थापित अद्यतन: हम देखेंगे कि यह कैसा चल रहा है! (बहुत बहुत धन्यवाद।)

मुझे यकीन नहीं है कि इन दिनों ऑटोजंप के लिए डेबियन पैकेज का रखरखाव कौन करता है, लेकिन यह संभव है कि वे केवल स्थिर टैग का निर्माण करते हैं। जबकि मास्टर शाखा v22.5.3 पर> 6 महीने के लिए रही है, मैंने आज रात केवल v22.5.3 को टैग किया है।

इस यादृच्छिक डेटा हानि से निपटने के लिए आपका सबसे अच्छा दांव इन निर्देशों का पालन ​​करते हुए स्रोत से स्थापित करना है।