2011-11-30 9 views
9

गुवा 10+ में, Google ने Files.deleteDirectoryContents() को हटा दिया। जावाडॉक कहता हैफ़ाइलों को क्यों हटाया जाता है .deleteDirectoryContents() गुवा में बहिष्कृत?

बहिष्कृत। यह विधि खराब सिम्लिंक पहचान और दौड़ स्थितियों से ग्रस्त है। इस कार्यक्षमता को केवल द्वारा समर्थित ऑपरेटिंग सिस्टम कमांड जैसे आरएम-आरएफ या डेल/एस के रूप में उपयुक्त रूप से समर्थित किया जा सकता है। इस विधि अमरूद में अमरूद से हटाया जा करने के लिए अनुसूचित रिलीज 11,0

मैं क्यों वहाँ एक रेस स्थिति है पर उलझन में हूँ। मुझे लगता है कि यह विधि वास्तव में उपयोगी है और ऑपरेटिंग सिस्टम को एक खराब समाधान के लिए खोलने लगती है। लेखक क्या साझा कर सकते हैं इस निर्णय को क्यों बनाया?

+0

अधिक स्पष्ट होने के लिए, मुझे लगता है कि दौड़ की स्थिति समस्या होने पर एक बड़ी बग नहीं है। 'अरेरेस्टिस्ट' जैसी कई libs थ्रेड सुरक्षित नहीं हैं या दौड़ की स्थिति नहीं हैं। यहां तक ​​कि 'File.remove' भी एक ही समस्या है। लेकिन वे सभी दस्तावेज हैं। तो मैं एक उत्तर सुनने की उम्मीद कर रहा था इसके अलावा दस्तावेज पहले से ही कहता है कि उन्होंने इसे बहिष्कृत करने का फैसला क्यों किया। –

+1

इस दौड़-स्थिति और सामान्य गैर-थ्रेड-सुरक्षित कक्षाओं के बीच का अंतर यह है कि इसके लिए कोई "ठीक" नहीं है। इसके विपरीत, आप लॉक ऑब्जेक्ट पर सिंक्रनाइज़ करके गैर थ्रेड-सुरक्षित कक्षाओं के साथ जावा थ्रेड-सुरक्षा समस्याओं को हल कर सकते हैं। एक तरीका जो बस ऐसा नहीं कर सकता जो लोग इसे करने की अपेक्षा करते हैं वह एक बुरी विधि है। –

+0

यह एक अच्छा मुद्दा है। धन्यवाद। –

उत्तर

5

मैं उलझन में हूं कि दौड़ की स्थिति क्यों है।

उदाहरण के लिए, मान लीजिए कि एक धागा Files.deleteDirectoryContents() कॉल करता है और एक दूसरे धागा (या एक बाहरी प्रक्रिया) एक साथ निर्देशिका में एक नई फ़ाइल बनाता है।

जब आप कॉल से वापस आते हैं, तो क्या आप निर्देशिका खाली होने पर भरोसा कर सकते हैं? नहीं!

वैसे भी, यदि आपको इस विधि की कार्यक्षमता उपयोगी होने के लिए मिलती है ... इसकी त्रुटियों के बावजूद ... आप कोड की एक प्रतिलिपि लेने, इसे ट्वीक करने और इसे अपने एप्लिकेशन में एम्बेड करने के लिए स्वतंत्र हैं। (बस गुवा स्रोत कोड लाइसेंस की जांच करें और सुनिश्चित करें कि आप इसके अनुरूप हैं।)

लेखकों को यह निर्णय क्यों दिया जा सकता है?

मुझे लगता है कि उनके पास पहले से ही है; बहिष्करण नोटिस देखें। यदि आप और चाहते हैं, तो समस्या ट्रैकर और गुवा चर्चा समूह को खोजने का प्रयास करें। आप चर्चा समूह पर विनम्रता से पूछने की कोशिश भी कर सकते हैं, भले ही आपका एजेंडा अपने दिमाग को बदलना है, मुझे संदेह है कि आप सफल होंगे।

+4

ओएस को खोलने के लिए भी यही सच होगा, है ना? – anders

+0

+1 ओएस को सच खोलने के समान नहीं होगा। मुझे लगता है कि यदि लाइब्रेरी थ्रेड सुरक्षित नहीं है तो इसे दस्तावेज किया जाना चाहिए और डेवलपर को यह सुनिश्चित करने के लिए कि वे इसे सही तरीके से उपयोग करें। –

+0

@ स्टीफन सी, मैं किसी भी शरीर के दिमाग को बदलने की कोशिश नहीं कर रहा हूं। मुझे यकीन है कि इस पर बहिष्कार क्यों किया गया है इसका एक अच्छा कारण है। मैंने सोचा कि दौड़ की स्थिति के अलावा शायद एक समस्या थी जो इसे करने के लिए मजबूर हुई। लेकिन ऐसी कई बहसें हैं जिनमें दौड़ की स्थिति है। मैंने सोचा कि शायद एक बेहतर कारण होगा। –

5

दौड़ की स्थिति संभावित रूप से खराब हो सकती है "निर्देशिका खाली नहीं हो सकती है" और यह खराब सिम्लिंक पहचान के कारण भाग में है। इस कोड स्निपेट पर विचार करें:

// Symbolic links will have different canonical and absolute paths 
if (!directory.getCanonicalPath().equals(directory.getAbsolutePath())) { 
    return; 
} 
... delete its contents ... 

तो directory जांच के दौरान एक सादे निर्देशिका लेकिन / बाद में करने के लिए एक सिमलिंक है, deleteDirectoryContents खुशी से पूरे फाइल सिस्टम को साफ करने के प्रयास करेंगे।

शायद कोई कामकाज है, लेकिन हमें यह नहीं मिला है। और एक संभावित सुरक्षा बग के लिए विज्ञापन फिक्स करना डरावना है।

1

टूटी सिम्लिंक पहचान के अधिक उदाहरणों के लिए, these bugs filed by users देखें।

संक्षेप में, निर्देशिका को मिटा देना असंभव है जब तक कि आप उस निर्देशिका के लिए कैननिकल पथ प्रदान न करें। यदि /tmp/some/other/directory का एक लिंक है, deleteDirectoryContents/tmp/mytempdirectory मिटा नहीं सकता है। शायद यहां एक संभावित कामकाज भी है, लेकिन हमने अपने हाथ फेंक दिए।

1

क्या आप गंभीर हैं? आप मल्टीथ्रेडिंग ऑपरेशंस को हल करने का प्रयास कर रहे हैं:

उदाहरण के लिए, मान लीजिए कि एक थ्रेड फ़ाइलें कॉल करता है।deleteDirectoryContents() और एक दूसरा थ्रेड (या बाहरी प्रक्रिया) एक साथ निर्देशिका में एक नई फ़ाइल बनाता है। जब आप कॉल से वापस आते हैं, तो क्या आप खाली होने वाली निर्देशिका पर भरोसा कर सकते हैं? नहीं!

और निर्देशिका पर किसी अन्य प्रक्रिया के बारे में क्या है ??? इसे हल नहीं किया जा सकता है और आपको लेनदेन को संभालना नहीं चाहिए क्योंकि यह संभव नहीं है। और तर्क है कि कोई व्यक्ति रूट करने के लिए सिम्लिंक बनाता है इसलिए मैं पूरी फाइल सिस्टम को हटा देता हूं - फाइल सिस्टम को संभालने के अधिकारों को प्राप्त नहीं करना चाहिए? और यदि आप रूट के रूप में इस तरह के ऑपरेशन चला रहे हैं तो आपको पता होना चाहिए कि आप क्या कर रहे हैं। फाइल सिस्टम में फाइलों को हटाने में अक्षमता के बारे में क्या, यह खतरनाक है !!! अगर गुवा के लेखक इस तरह की बेवकूफ समस्याओं को हल करते हैं तो मैं अलग-अलग लाइब्रेरी का उपयोग करूंगा।

संबंधित मुद्दे