Cargo build अटक गया: "Blocking waiting for file lock" – समाधान

शुरुआती लोगों के लिए ऑनलाइन Python प्रशिक्षक

Python आसानी से सीखें बिना सिद्धांत के बोझ के। स्वचालित जांच के साथ व्यावहारिक कार्य हल करें और ब्राउज़र में सीधे कोड लिखें।

पाठ्यक्रम शुरू करें

परिचय: जब Rust कंपाइलेशन एक चुनौती बन जाए

\n\n

आपने Parity (या कोई अन्य जटिल Rust प्रोजेक्ट) को सोर्स कोड से बिल्ड करने का फैसला किया। cargo build कमांड चलाई, टर्मिनल चुप है, और एक मिनट बाद आपको यह परिचित संदेश दिखता है:

\n\n
Blocking waiting for file lock on the registry index
\n\n

बिल्ड पूरी तरह से अटक जाता है। Ctrl+C काम नहीं करता, टर्मिनल को रीस्टार्ट करने से भी कोई फायदा नहीं। परिचित लग रहा है? यह समस्या Stack Overflow पर सबसे लोकप्रिय में से एक है (हजारों व्यूज), और आज हम इसे पूरी तरह से समझेंगे।

\n\n

इस लेख में, मैं आपका Rust की दुनिया में गाइड हूँ, बताऊंगा:
\n- यह त्रुटि क्यों होती है?
\n- इसे 30 सेकंड में कैसे ठीक करें?
\n- इसे होने से कैसे रोकें?
\n- और Cargo के अंदरूनी कामकाज पर एक नज़र डालेंगे।

\n\n

चलिए शुरू करते हैं! 🚀

\n\n

"Blocking waiting for file lock on the registry index" कहाँ से आता है?

\n\n

पहले, इस त्रुटि को Cargo की भाषा से आम भाषा में अनुवाद करते हैं:

\n\n

"मैं, Cargo, रजिस्ट्री से पैकेजों की सूची डाउनलोड या अपडेट करना चाहता हूँ, लेकिन नहीं कर सकता – लॉक फ़ाइल पहले से किसी दूसरे प्रोसेस द्वारा उपयोग की जा रही है। इंतज़ार कर रहा हूँ..."

\n\n

Rust इकोसिस्टम में, cargo फ़ाइल लॉक (.lock फ़ाइलें) का उपयोग करता है ताकि दो प्रोसेस एक साथ रजिस्ट्री कैश (~/.cargo/registry) में न लिखें। यह डेटा भ्रष्टाचार से बचाता है, लेकिन कभी-कभी लॉक "अटक" जाता है।

\n\n

अटकने के मुख्य कारण

\n
    \n
  • पिछली बिल्ड का अचानक समाप्त होना – आपने टर्मिनल बंद कर दिया, कंप्यूटर बंद हो गया, या cargo build क्रैश हो गया, लेकिन लॉक फ़ाइल बनी रही।
  • \n
  • एक ही प्रोजेक्ट में Cargo के दो इंस्टेंस – दो टर्मिनल विंडो में एक साथ बिल्ड चलाना।
  • \n
  • Parity को सोर्स से बिल्ड करना – यह प्रोजेक्ट बहुत सारी डिपेंडेंसी (सैकड़ों क्रेट) खींचता है, और Cargo इंडेक्सिंग चरण में अटक सकता है, खासकर कमज़ोर मशीनों या धीमे इंटरनेट पर।
  • \n
  • एक्सेस परमिशन की समस्या – शायद ही, लेकिन जब ~/.cargo किसी दूसरे यूज़र का हो।
  • \n
  • फ़ाइल सिस्टम जो लॉकिंग को सपोर्ट नहीं करता – जैसे कुछ नेटवर्क शेयर या बिना सही कॉन्फ़िगरेशन के WSL।
  • \n
\n\n

5 समाधान (तेज़ से विश्वसनीय तक)

\n\n

🔧 तरीका 1: Cargo प्रोसेस को खत्म करें (सबसे तेज़)

\n

अगर आपको यकीन है कि कोई दूसरी बिल्ड नहीं चल रही है, तो बस उस प्रोसेस को खत्म करें जो लॉक को पकड़े हुए है।

\n\n

Linux/macOS:

\n
pkill cargo\n# या और सख्त:\nkillall -9 cargo
\n\n

Windows (PowerShell):

\n
Get-Process cargo | Stop-Process -Force
\n\n

इसके बाद cargo build फिर से चलाएँ। 80% मामलों में यह काफी है।

\n\n

🔧 तरीका 2: लॉक फ़ाइल को मैन्युअली हटाएँ

\n

अगर पहला तरीका काम नहीं करता, तो रजिस्ट्री डायरेक्टरी में जाएँ और लॉक फ़ाइल को हटा दें।

\n\n

पथ:

\n
# Linux/macOS\nrm -f ~/.cargo/registry/.cache-lock\nrm -f ~/.cargo/registry/.package-cache\n\n# Windows (cmd)\ndel %USERPROFILE%\\.cargo\\registry\\.cache-lock\ndel %USERPROFILE%\\.cargo\\registry\\.package-cache
\n\n

इसके बाद, Cargo अगली बार चलने पर एक नई लॉक फ़ाइल बनाएगा। महत्वपूर्ण: सुनिश्चित करें कि Cargo का कोई अन्य प्रोसेस नहीं चल रहा है, अन्यथा आप कैश को नुकसान पहुँचा सकते हैं।

\n\n

🔧 तरीका 3: Cargo clean – परमाणु विकल्प

\n

अगर कुछ भी काम नहीं करता, तो सब कुछ साफ़ करें। यह target फ़ोल्डर को हटा देगा और मौजूदा प्रोजेक्ट के लिए डिपेंडेंसी कैश को रीसेट कर देगा। अगली बिल्ड में अधिक समय लगेगा, लेकिन यह साफ़ होगी।

\n\n
cargo clean
\n\n

इसके बाद प्रोजेक्ट को फिर से बिल्ड करने का प्रयास करें:

\n
cargo build
\n\n

यह तरीका विशेष रूप से उपयोगी है यदि आप Parity या विशाल डिपेंडेंसी ट्री वाले किसी अन्य प्रोजेक्ट को बिल्ड कर रहे हैं।

ब्लॉग

पुस्तक अनुशंसाएँ