2013-01-06 8 views
7

मेरे आवेदन में (सी # 4.5 विनफॉर्म ऐप) मैं समय-समय पर किसी फ़ोल्डर की सामग्री की जांच करता हूं और डेटाबेस में मिली किसी भी फाइल का विवरण संग्रहीत करता हूं। इस दिनचर्या के भीतर, मैं उदाहरण new FileInfo(path) का उपयोग कर उदाहरण बनाता हूं, और मैंने CreationTime, LastWriteTime, LastAccessTime, Length और Attributes गुणों को पढ़ा है। मैंने कभी भी FileInfo उदाहरण पर कोई भी तरीका नहीं बुलाया।क्या वर्तमान में इस फ़ाइल पर एक फ़ाइलइन्फो बनाने के लिए सुरक्षित है?

जो मैं जानना चाहता हूं: क्या भ्रष्टाचार, लॉकिंग या रनटाइम त्रुटियों का कोई खतरा है यदि वर्तमान में किसी फ़ाइल को किसी तृतीय पक्ष एप्लिकेशन (या विंडोज द्वारा फ़ोल्डर में कॉपी करने की प्रक्रिया में) द्वारा लिखा जा रहा है, FileInfo ऑब्जेक्ट बनाएं या इसकी संपत्तियों का उपयोग करें?

उत्तर

11

हां, यह "सुरक्षित" है। यह फ़ाइल सिस्टम ड्राइवर बहुत कम स्तर पर निपटाया जाता है। एफएटी या एनटीएफएस जैसी सामान्य फाइल सिस्टम पर एक फ़ाइल में दो डिस्क पर अलग-अलग संरचनाएं हैं। सबसे पहले निर्देशिका प्रविष्टि है, यह फ़ाइल के बारे में मेटाडेटा स्टोर करता है। नाम, टाइमस्टैम्प, विशेषताओं और लंबाई की तरह। वास्तविक फ़ाइल डेटा कहीं और संग्रहीत किया जाता है, क्लस्टर की एक श्रृंखला जो फ़ाइल डेटा संग्रहीत करती है।

FileInfo विशेष रूप से आपको फ़ाइल के लिए मेटाडेटा देता है। फाइल डेटा एक प्रक्रिया के रूप में बदलने के रूप में फ़ाइल डेटा अधिक संवेदनशील है, अत्यधिक परिवर्तन के अधीन है। उल्लेखनीय है कि आप फ़ाइलशेयर विकल्पों के साथ फ़ाइल डेटा तक पहुंच को लॉक कर सकते हैं। लेकिन मेटाडेटा को लॉक करने का कोई तरीका नहीं है। तदनुसार आप फाइल के लिए फाइलइन्फो हमेशा प्राप्त कर सकते हैं, भले ही फ़ाइल के साथ एक और प्रक्रिया क्या कर रही हो।

बेशक, फ़ाइल में एक प्रक्रिया लिखते समय वास्तविक फ़ाइलइन्फो गुण बदल सकते हैं। उन्हें आलसी, विशेष रूप से LastAccessTime प्रॉपर्टी अपडेट किया गया है। यदि आप यह सुनिश्चित करना चाहते हैं कि आपको सटीक जानकारी मिल गई है जो बदल नहीं सकती है तो आपको फ़ाइल पर लॉक प्राप्त करने की आवश्यकता है। फ़ाइलशेयर के साथ फ़ाइल खोलकर ऐसा करें। पढ़ें या FileShare.None।जो सुनिश्चित करता है कि जब तक आपके पास फ़ाइल खुलती है, तब तक कोई अन्य प्रक्रिया फ़ाइल को लिखने के लिए नहीं खोल सकती है। ध्यान दें कि कि आसानी से IOException फेंक सकता है, आप केवल तब लॉक प्राप्त करेंगे जब कोई अन्य प्रक्रिया आपके सामने नहीं आई थी और फ़ाइल को लिखने के लिए खोला गया था।

+0

विस्तृत स्पष्टीकरण के लिए बहुत बहुत धन्यवाद। मुझे विश्वास दिलाता है कि मेरा कोड सुरक्षित है। यदि मैं FileShare.None का उपयोग कर फ़ाइल में लिखना चाहता हूं, तो मैं अलग-अलग एक्सेस की जांच करता हूं, लेकिन इस विशेष मामले में मुझे केवल मेटाडाटा चाहिए और अब मैं इसे पढ़ने के बारे में भरोसा कर सकता हूं को लिखा – wwarby

1

नहीं, वे उस संदर्भ में नहीं हैं जिसका आप उपयोग कर रहे हैं।

से FileSystemInfo.LastWrite -> MSDN

नोट इस विधि क्योंकि यह देशी कार्यों जिनके मान लगातार ऑपरेटिंग सिस्टम के द्वारा अद्यतन नहीं किया जा सकता का उपयोग करता है, एक गलत मूल्य वापस आ सकते हैं।

लेकिन एक सेकंड के लिए कल्पना कीजिए, वे नवीनतम मूल्य लौट रहे थे। यदि आपने मूल्य (समय पर निर्भर) का उपभोग किया है, और उसके बाद फ़ाइलों को ओवरराइट किया गया है, तो आपके अंतिम एक्सेस किए गए मान गलत/दूषित हो जाएंगे। तो यह समझ में नहीं आता है।

0

कोई समस्या नहीं MSDN देखें:

http://msdn.microsoft.com/en-us/library/system.io.fileinfo.aspx

थ्रेड सुरक्षा किसी भी सार्वजनिक स्थैतिक (विजुअल बेसिक में साझा) इस प्रकार के सदस्यों धागा सुरक्षित हैं। किसी भी इंस्टेंस सदस्यों को थ्रेड सुरक्षित होने की गारंटी नहीं है।

और नोटिस:

जब गुण पहले प्राप्त किए गए हैं, FileInfo ताज़ा प्रणाली को बुलाती है और फाइल के बारे में जानकारी संचित करता है। बाद की कॉल पर, आपको जानकारी की नवीनतम प्रति प्राप्त करने के लिए ताज़ा करना होगा।

+1

लेकिन फ़ाइल ऑब्जेक्ट लगातार संशोधित होने पर दौड़ होती है। – Tilak

+0

वे इसे अपने स्तर पर संभालते हैं और आपको वादा करते हैं कि जब तक आप स्थिर विधि का उपयोग करते हैं तो आपको एक सुरक्षित परिणाम मिल जाएगा। यह ** सबसे ** ** नहीं हो सकता है लेकिन डेटा खराब नहीं होगा। – Nahum

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