Gradle Temporary workspace त्रुटि समाधान प्रक्रिया का विस्तृत विवरण

• Gradle 8.6 से Windows वातावरण में एंटीवायरस प्रोग्राम के साथ टकराव के कारण 'Could not move temporary workspace...' त्रुटि आकर build बार-बार fail होने लगा था, लेकिन Gradle 9.1 RC में यह आखिरकार ठीक हो गया।
• Windows उपयोगकर्ता जो एक साल से अधिक समय से इस build error का सामना कर रहे थे, वे 9.1 संस्करण से सामान्य रूप से Gradle build चला पाएँगे। (संबंधित issue: #31438)

पहले के संस्करणों में काम करने का तरीका

• फाइल पर सीधे file lock लगाकर dependency cache की immutability सुनिश्चित की जाती थी। यह तरीका सरल और स्पष्ट था।

8.6 संस्करण से काम करने का तरीका

• परफॉर्मेंस बेहतर करने के लिए CacheBasedImmutableWorkspaceProvider को लाया गया, जो UUID आधारित temporary files बनाता है और काम खत्म होने के बाद उन्हें unique path पर move कर देता है।
• यह तरीका integration test के दौरान file lock तरीके से होने वाले performance slowdown को सुलझाने के लिए अपनाया गया था।
• Windows वातावरण में एंटीवायरस प्रोग्राम की real-time monitoring (नई फाइल बनते ही lock लेना) के साथ टकराव के कारण temporary file move fail होने की समस्या आई।

9.1 संस्करण का patch तरीका

• ऑपरेटिंग सिस्टम के हिसाब से अलग locking strategy लागू की गई।
• Windows वातावरण: LockingStrategy.WORKSPACE_LOCK तरीका अपनाया गया। यह cache path के अंदर subdirectory (\workspace) बनाता है और उस पूरे subdirectory पर lock लेकर एंटीवírus के per-file दखल को रोकता है, जिससे समस्या सुलझती है।
• Windows के बाहर के वातावरण: 8.6 तरीके का existing ATOMIC_MOVE बना रहेगा.

[click]

मैंने यह ब्लॉग पोस्ट इसलिए लिखी क्योंकि मैंने इसे खुद काफी कष्ट उठाकर संभाला और जब PR मर्ज हो गया तो लिख दिया। show तो सीधे विकसित किए गए प्रोडक्ट दिखाने की जगह है, इसलिए शायद वहाँ डालना ठीक नहीं लगता, इसलिए मैंने इसे सामान्य न्यूज़ के रूप में पोस्ट कर दिया—हालाँकि मुझे पता नहीं यह सही फैसला था या नहीं.