File.delete() को झूठा लौटने/अनजान धाराओं का पता लगाने का निदान कैसे करें?

Question

मैं एक तृतीय पक्ष जेपीईजी/EXIF ​​मैनिपुलेशन लाइब्रेरी (Mediautil) के साथ काम कर रहा हूं जो मुझे कुछ सिरदर्द पैदा कर रहा है। मैं एक छवि के EXIF ​​डेटा को बदलना चाहता हूं। ऐसा करने के लिए, मुझे अद्यतन संस्करण को अस्थायी फ़ाइल में लिखना होगा, मूल को हटाएं और फिर मूल नाम पर temp फ़ाइल का नाम बदलें। लेकिन मैं यह सब धाराओं को बंद करने के लिए सब कुछ मैं एपीआई में पा सकते हैं किया है -

मेरे समस्या शायद क्योंकि पुस्तकालय अभी भी यह किसी तरह से खोल दिया है कि File.delete() कॉल के विफल होने और false देता है,। इससे भी बदतर: समस्या समय-निर्भर होने लगती है, और यूनिट परीक्षण जहां कभी-कभी असफल होता है और कभी-कभी नहीं होता - लेकिन कोड बहुप्रचारित नहीं है।

विचित्र रूप से, एक पुस्तकालय कॉल है जो समस्या को हटा देता है - लेकिन यह EXIF ​​थंबनेल को भी हटा देता है, जिसे मैं वास्तव में नहीं चाहता हूं। और कोड को देखते हुए, मैं बिल्कुल नहीं देख सकता कि यह किसी भी धारा को बंद करता है जो अन्यथा खुला रहता है।

कोई भी विचार इस समस्या पर हमला कैसे करें?

संपादित करें: यह Windows XP, जावा 6. और एक और बात पर है: मुझे पता चला है कि अगर मैं File.delete() कॉल करने से पहले System.gc() कहते हैं, यह काम करता है - शायद क्योंकि है कि कुछ finalizer से चलाता है। तो यह निश्चित रूप से एक संलग्न धारा प्रतीत होता है।

Answer 1

मैं यहां डीबगर के साथ कुछ मदद के लिए जाऊंगा। java.io सामग्री के माध्यम से एक त्वरित खुदाई से पता चलता है कि केवल finalize() उम्मीदवार FileOutputStream में है। तो वहां एक ब्रेकपॉइंट थप्पड़ मारो, अपना प्रोग्राम चलाएं, और अपनी स्ट्रीम को रिलीज़ करने के लिए FileOutputStream.finalize() को ट्रिगर करने के लिए System.gc() प्राप्त करें और प्राप्त करें। इससे आपको जवाब मिलना चाहिए कि यह आपकी समस्या है या नहीं।

एक बार जब आप इसे पुन: उत्पन्न कर सकते हैं, तो आपको उनके अंतिमकरण के साथ FileOutputStream उदाहरणों के मिलान की तत्कालता शुरू करने की आवश्यकता है। एक अच्छा डीबगर आपको प्रत्येक ऑब्जेक्ट के लिए आंतरिक जेवीएम ऑब्जेक्ट आइडेंटिफायर देगा, इसलिए यदि आप ओआईडी को ट्रैक करते समय ट्रैक कर सकते हैं, और उन्हें अंतिम रूप देने के रूप में ट्रैक कर सकते हैं, तो उम्मीद है कि आप कुंजी कॉल को finalize से संबद्ध कर पाएंगे विशिष्ट कॉल नया new FileOutputStream।

एक लंबा स्लोग हो सकता है, हालांकि, यह निर्भर करता है कि आपका आवेदन कितना जटिल है।

Answer 2

लाइब्रेरी को खोलने से पहले आप फ़ाइल का नाम क्यों नहीं बदलते? फिर नामित फ़ाइल को हटाने के लिए शायद जावा की File.deleteOnExit() का उपयोग करें। उदाहरण के लिए:

File jpeg = new File("image.jpg"); 
File temp = new File(jpeg + ".temp.jpg"); 
jpg.renameTo(temp); 
SomeObj result = exifLibrary(temp); // or exifLibrary(new FileInputStream(temp); 
OutputStream jpegStream = new FileOutputStream(jpeg); 
output.write(result.bytes(); 
output.close(); 
temp.deleteOnExit(); 
temp.delete(); 

Answer 3

और कोड को देखते हुए, मैं बिल्कुल नहीं देख सकते हैं, जहां यह किसी भी धाराओं है कि अन्यथा खुला रह सकता है बंद कर देता है।

मुझे लगता है कि आप वास्तविक समस्या की पहचान कर सकते थे; यानी कि आप जिस एपीआई का उपयोग कर रहे हैं वह डिज़ाइन द्वारा खुले फ़ाइल हैंडल का उपयोग कर रहा है।

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

Answer 4

यदि आप FileOutputStream का उपयोग कर रहे हैं, तो इसे बंद करने से स्पष्ट रूप से फ़ाइल को हटाने की अनुमति मिलती है।

उदा। के बजाय:

File myFile = new File("test.txt"); 
myCustomStreamProcess(new FileOutputStream(myFile)); 
boolean test = myFile.delete(); //May return false 

आपको क्या करना चाहिए:

File myFile = new File("test.txt"); 
FileOutputStream fos = new FileOutputStream(myFile); 
myCustomStreamProcess(fos); 
fos.close(); //Allow the document to be deleted afterwards 
boolean test = myFile.delete(); //Should always return true