फिर छिद्रपूर्ण अमूर्त (या अप्रत्याशित वातावरण के बारे में)

तो, विंडोज के लिए कार्यक्रम का एक काफी सरल हिस्सा है। कई प्रविष्टियों वाली एक फ़ाइल है। और उन्हें एक निश्चित तरीके से फ़िल्टर करने की आवश्यकता है।

समाधान काफी सरल है - फ़ाइल खोलें, एक-एक करके रिकॉर्ड पढ़ें, हम एक अस्थायी फ़ाइल के लिए आवश्यक लिखते हैं। फ़ाइल बंद करें। हम इसे हटा देते हैं। अस्थायी को मूल नाम दें। सब कुछ इतना सरल है कि मैंने कोड भी नहीं दिया है। क्या यह वास्तव में लेख के लिए पर्याप्त कारण है?

जबकि सब कुछ काम करता है, वास्तव में इसके बारे में लिखने का कोई कारण नहीं है। लेकिन फिर अचानक एक दिन "सब कुछ गिर जाता है", क्योंकि पहुँच अस्वीकृत त्रुटि के कारण नाम बदलना नहीं होता है। यह बहुत कम ही होता है, लेकिन अभी भी अधिक बार ब्रह्मांडीय किरणों पर संदेह करने के लिए।

हम खुदाई शुरू करते हैं। पहला सुराग मिला: खुदाई की प्रक्रिया में, Microsoft प्रलेखन के इस उद्धरण को सतर्क किया गया:

DeleteFile फ़ंक्शन क्लोज़ को डिलीट करने के लिए एक फ़ाइल को चिह्नित करता है। इसलिए, फ़ाइल हटाना तब तक नहीं होता है जब तक कि फ़ाइल का अंतिम हैंडल बंद न हो जाए। ERROR_ACCESS_DENIED के साथ फ़ाइल को खोलने के लिए CreateFile को अनुवर्ती कॉल।

लक्षणों के संदर्भ में, यह बहुत समान है, लेकिन ये "अन्य हैंडलर" कहां से आते हैं, अगर, हमारे अलावा, कोई भी इस फाइल के साथ कुछ नहीं करता है और क्या नहीं करना चाहिए? और हमारे पास धागे के साथ कोई अन्य धागे नहीं हैं जो इस फ़ाइल के साथ कुछ करेंगे?

दोषी को SysInternals और उनके ProcessMonitor का धन्यवाद मिला। हम इसे लॉन्च करते हैं, हमारी लंबी-पीड़ित फ़ाइल पर फ़िल्टर स्थापित करते हैं और इसे लंबे और लगातार के लिए पुन: पेश करने का प्रयास करते हैं। हम प्रजनन करते हैं। हम देखते हैं। और हम वहां क्या देखते हैं?

01.2: 30: 28.3162097 PM our_prog.exe 1288 CreateFile our.file SUCCESS वांछित पहुंच: सामान्य पढ़ें / लिखें
०२.२: २५: २ our.३१६४५१३ अपराह्न हमारा_प्रो। १२File हमारी समीक्षा करें। हमारी सफलता का आधार: ०, लंबाई:, ९,, प्राथमिकता: सामान्य
...
34.2: 25: 28.3173405 PM our_prog.exe 1288 WriteFile our.file SUCCESS ऑफसेट: 35,290, लंबाई: 1,113
35.2: 25: 28.3173493 अपराह्न our_prog.exe 1288 हमारी समीक्षा करें। हमारी SUCCESS ऑफसेट: 36,403, लंबाई: 1,128
36.2: 25: 28.3173736 PM our_prog.exe 1288 FlushBuffersFile our.file SUCCESS
37.2: 25: 28.3174212 PM our_prog.exe 1288 हमारा ईमेल लिखें। हमारा SUCCESS ऑफसेट: 0, लंबाई: 40,960
38.2: 25: 28.3175927 PM Explorer.EXE 1884 QueryBasicInformationFile our.free SUCCESS
39.2: 25: 28.3176144 PM Explorer.EXE 1884 बंद करें। हमारा SUCCESS
40.2: 25: 28.3263642 PM Explorer.EXE 1884 CreateFile our.file SUCCESS वांछित पहुंच: पढ़ें विशेषताएँ,
41.2: 25: 28.3294990 PM our_prog.exe 1288 बंद करें। हमारा। SUCCESS
42.2: 25: 28.3351356 PM our_prog.exe 1288 CreateFile our.file SUCCESS वांछित पहुंच: पढ़ें विशेषताएँ, हटाएं,
43.2: 25: 28.3351856 PM our_prog.exe 1288 QueryAttributeTagFile हमारी.फाइल SUCCESS विशेषताएँ: A, ReparseTag: 0x0
44.2: 25: 28.3352020 PM our_prog.exe 1288 SetDispositionInformationFile our.file SUCCESS हटाएं: सच
45.2: 25: 28.3352218 पीएम our_prog.exe 1288 बंद करें। हमारा SUCCESS
46.2: 25: 28.3358275 PM Our_prog.exe 1288 CreateFile our.file DELETE PENDING Desired Access: Generic Read / Write,
47.2: 25: 28.3362207 PM our_prog.exe 1288 CreateFile our.file DELETE PENDING Desired Access: Generic Read / Write,
48.2: 25: 28.3367696 PM Explorer.EXE 1884 QueryBasicInformationFile हमारी.fx SUCCESS
49.2: 25: 28.4279152 PM Explorer.EXE 1884 बंद करें। हमारा SUCCESS
50.2: 25: 28.4282859 PM Explorer.EXE 1884 CreateFile our.file NAME NOT FOUND Desired Access: Read Attributes,
...
83.2: 25: 29.3497760 PM our_prog.exe 1288 CreateFile our.file SUCCESS वांछित पहुंच: सामान्य पढ़ें / लिखें

और हम निम्नलिखित देखते हैं (अतिरिक्त डेटा हटा दिया गया था ताकि अव्यवस्था न हो)। लाइनें 1 से 36 - हम एक फाइल बनाते हैं, इसे लिखते हैं, फ्लश बनाते हैं। सबसे दिलचस्प 38-40 लाइनों में शुरू होता है। Explorer.exe कहीं से प्रकट होता है और हमारी फ़ाइल पढ़ना शुरू कर देता है।

लाइन 41 पर हम अपनी फाइल को बंद करते हैं। 42 लाइन में - हटाएं। और चूंकि explorer.exe अभी भी इसे पढ़ रहा है, फ़ाइल को हटाया नहीं गया है। जब हम अपनी अस्थायी फ़ाइल को मुख्य एक (DELETE PENDING स्थिति SUCCESS के बजाय स्थिति) में बदलने का प्रयास करते हैं, तो हम 46 और 47 की तर्ज पर देख सकते हैं।

Explorer.exe केवल 49 लाइन पर पढ़ने को समाप्त करता है। केवल उस क्षण में फ़ाइल को भौतिक रूप से हटा दिया जाता है (जैसा कि लाइन 50 अप्रत्यक्ष रूप से हमें बताता है, जहां हमारा लगातार एक्सप्लोरर .1 फिर से पढ़ने के लिए फ़ाइल को खोलने की कोशिश करता है, लेकिन यह विफल रहता है क्योंकि फ़ाइल अब नह) ं है।

इससे क्या होता है? माइक्रोसॉफ्ट विंडोज के लिए धन्यवाद, यहां तक ​​कि एक साधारण फ़ाइल हटाने का ऑपरेशन भी अब पैरानॉयड प्रोग्रामिंग की शैली में किया जाना चाहिए। उन्होंने डिलीट फंक्शन को कॉल किया, यह सुनिश्चित किया कि यह ठीक है, और प्रतीक्षा चक्र में प्रवेश किया "जब तक कि फ़ाइल को अभी तक भौतिक रूप से हटाया नहीं गया है।" अच्छी तरह से और हाँ, यह जाने बिना कि "उसके पास एक नीयन है," लगभग कुछ भी नहीं किया जा सकता है ...

लेकिन अब मुझे संदेह हो रहा है कि इस तरह का दृष्टिकोण एक आम तौर पर स्वीकृत अभ्यास है। विंडोज में फ़ाइलों के साथ किसी भी काम के दौरान ध्यान में रखने के लिए कि ओएस किसी भी समय आपकी जानकारी के बिना फाइलों के साथ कुछ करने का फैसला करता है, और कोड लिखता है जो इसके लिए प्रतिरोधी है। इस संबंध में, सर्वेक्षण कम है।