2009-11-18 27 views
7

मैं एक ही लड़ी कार्यक्रम (सी ++, Win32, NTFS) जो पहले एक काफी लंबा अस्थायी फ़ाइल बनाता है, जिसे बंद कर देता है, पढ़ने के लिए खोलता है, पढ़ता है, फिर से बंद कर देता है और DeleteFile() का उपयोग कर नष्ट करने के लिए कोशिश करता है है।DeleteFile पर विफल रहता है हाल ही में बंद फ़ाइल

आमतौर पर यह आसानी से चला जाता है, लेकिन कभी-कभी DeleteFile() विफल रहता है, और GetLastError() ERROR_ACCESS_DENIED लौटाता है। फ़ाइल केवल पढ़ने के लिए ही पढ़ा नहीं जाता है। यह किसी भी आकार की फाइलों पर होता है, लेकिन संभावना फ़ाइल के आकार के साथ बढ़ती है।

कोई भी विचार क्या फ़ाइल ताला लगा जा सकता है? मैंने WinInternals टूल्स को जांचने और कुछ भी संदिग्ध नहीं पाया।

+0

क्या आप वाकई यह हटाने का प्रयास करने से पहले फ़ाइल ठीक से बंद कर रहे हैं कर रहे हैं? क्या आपने किसी हैंडल को याद किया? – RageZ

+0

जैसा कि मैंने कहा, मैंने WinInternals टूल के साथ भी जांच की है। सभी खुलने को बंद कर दिया जाता है, लेकिन हटाना विफल रहता है। और 1 सेकंड के लिए सोते हुए समस्या को हल करता है। –

+0

यह खिड़कियां छोटी हो सकती हैं लेकिन मैं उस पर संदिग्ध हूं। यदि 'नींद' जोड़ना यह काम ठीक होना चाहिए ^^ – RageZ

उत्तर

1

हो सकता है कि परिवर्तन अभी भी संचित कर रहे हैं और अभी तक सहेजे नहीं गए हैं?

आप सुनिश्चित करने के लिए फ़ाइल हैंडल पर WaitForSingleObject जोड़कर इसे देख सकते हैं।

+3

कैशिंग लिखना एप्लिकेशन के लिए पारदर्शी है। यह व्यवहार में बदलाव नहीं करना चाहिए। –

4

, एक संदेशबॉक्स() कॉल करने से पहले आप DeleteFile आह्वान() जोड़े जब यह पता चलता है, sysinternals उपकरण प्रोसेस एक्सप्लोरर चलाते हैं। फ़ाइल में खुले हैंडल की खोज करें। सभी संभावना में आप फाइल करने के लिए सभी हैंडल बंद कर दिया है नहीं ...

+1

यही वह है जो मैंने शुरू किया था। कोई संभाल नहीं तो फिर मैंने फ़ाइल तक पहुंच को लॉग किया, और कुछ विशेष नहीं। –

+0

यह दौड़ की स्थिति (संभवतः मिलीसेकंड के क्रम पर) की तरह लगता है, इसलिए जब तक आप सब कुछ जमा नहीं करते हैं, तो आप इस तरह से बग को पुन: पेश नहीं कर पाएंगे। (लेकिन कोशिश कर निश्चित रूप से संभावनाओं को कम करने में मदद करता है।) –

8

बस एक जंगली अनुमान - आप किसी भी एंटी-वायरस सॉफ्टवेयर स्थापित है? क्या आपने ऐसा कोई वास्तविक समय सुरक्षा सुविधाओं को अक्षम करने का प्रयास किया है, यदि आप करते हैं?

+3

यह उत्तर पूरी तरह से सही होने का हकदार है। –

+0

ओह, मुझे इसके बारे में पता नहीं है। –

8

विंडोज इस मुद्दे के लिए कुख्यात है। एसक्लाइट प्रत्येक 100 मिलीसेकंड को अधिकतम संख्या तक हटाने के ऑपरेशन को पुनः प्रयास करके समस्या को संभालता है।

मेरा मानना ​​है कि यदि आप वाकई कोई खुला हैंडल है, अपने कार्यान्वयन में यह कर आप कुछ सिर दर्द की बचत होगी जब एंटीवायरस सॉफ्टवेयर जैसी चीजों फ़ाइल को खोलने हैं।

संदर्भ के लिए, SQLite स्रोत से टिप्पणी:

/*                  
** Delete the named file.            
**                  
** Note that windows does not allow a file to be deleted if some other 
** process has it open. Sometimes a virus scanner or indexing program 
** will open a journal file shortly after it is created in order to do 
** whatever it does. While this other process is holding the   
** file open, we will be unable to delete it. To work around this  
** problem, we delay 100 milliseconds and try to delete again. Up  
** to MX_DELETION_ATTEMPTs deletion attempts are run before giving  
** up and returning an error.           
*/ 
3

मेरा मानना ​​है कि इस Windows Internals में शामिल है। छोटी कहानी यह है कि भले ही आपने फ़ाइल हैंडल पर क्लोजहैंडल कहा है, फिर भी कर्नेल में बकाया संदर्भ हो सकते हैं जो बंद करने के लिए कुछ मिलीसेकंड लेते हैं।

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

#include <windows.h> 
#include <stdio.h> 

int wmain(int argc, wchar_t** argv) 
{ 
    LPCWSTR fileName = L"c:\\temp\\test1234.bin"; 

    HANDLE h1 = CreateFileW(
     fileName, 
     GENERIC_WRITE, 
     // make sure the next call to CreateFile can succeed if this handle hasn't been closed yet 
     FILE_SHARE_READ | FILE_SHARE_DELETE, 
     NULL, 
     CREATE_ALWAYS, 
     FILE_FLAG_SEQUENTIAL_SCAN | FILE_ATTRIBUTE_TEMPORARY, 
     NULL); 
    if (h1 == INVALID_HANDLE_VALUE) 
    { 
     fprintf(stderr, "h1 failed: 0x%x\n", GetLastError()); 
     return GetLastError(); 
    } 

    HANDLE h2 = CreateFileW(
     fileName, 
     GENERIC_READ, 
     // FILE_SHARE_WRITE is required in case h1 with GENERIC_WRITE access is still open 
     FILE_SHARE_WRITE | FILE_SHARE_READ | FILE_SHARE_DELETE, 
     NULL, 
     OPEN_EXISTING, 
     // tell the OS to delete the file as soon as it is closed, no DeleteFile call needed 
     FILE_FLAG_DELETE_ON_CLOSE | FILE_FLAG_SEQUENTIAL_SCAN | FILE_ATTRIBUTE_TEMPORARY, 
     NULL); 
    if (h2 == INVALID_HANDLE_VALUE) 
    { 
     fprintf(stderr, "h2 failed: 0x%x\n", GetLastError()); 
     return GetLastError(); 
    } 

    return 0; 
} 
+0

क्या यह विफल नहीं होगा अगर किसी अन्य प्रक्रिया ने एक ही फाइल खोला है, तो दस्तावेज़ से निम्नलिखित विवरण दिया गया है? "अगर फ़ाइल में मौजूदा खुले हैंडल हैं, तो कॉल विफल रहता है जब तक कि वे सभी FILE_SHARE_DELETE शेयर मोड के साथ खोले नहीं जाते।" –

+0

हां, यही कारण है कि मैंने लिखने और पढ़ने के बीच फ़ाइल हैंडल को बंद न करने की अनुशंसा की। FILE_FLAG_DELETE_ON_CLOSE के साथ पहला संभाल बनाएं और फिर आपको ReOpenFile या डुप्लिकेट हैंडल का उपयोग करें यदि आपको वास्तव में एक फ़ाइल हैंडल की आवश्यकता है जिसमें लेखन पहुंच नहीं है। –

+0

शायद मैं आज धीमा हूं, लेकिन क्या यह अभी भी कोई समस्या नहीं होगी यदि कोई स्नीकी फ़ाइल बनाने के लिए अंतिम कॉल से पहले फ़ाइल खोलता है? अंतिम कॉल अभी भी असफल हो जाएगा। –

0
#include <iostream> 
#include <windows.h> 

int main(int argc, const char * argv[]) 
{ 
    // Get a pointer to the file name/path 
    const char * pFileToDelete = "h:\\myfile.txt"; 
    bool RemoveDirectory("h:\\myfile.txt"); 

    // try deleting it using DeleteFile 
    if(DeleteFile(pFileToDelete)) 
    { 
     // succeeded 
     std::cout << "Deleted file" << std::endl; 
    } 
    else 
    { 
     // failed 
     std::cout << "Failed to delete the file" << std::endl; 
    } 
    std::cin.get(); 
    return 0; 
} 
संबंधित मुद्दे