FileSystemWatcher बनाम फ़ाइल परिवर्तन देखने के लिए मतदान

Question

मुझे एक एप्लिकेशन को सेटअप करने की आवश्यकता है जो एक निर्देशिका में निर्मित फ़ाइलों के लिए देखता है, दोनों स्थानीय रूप से या नेटवर्क ड्राइव पर।

चाहेंगे FileSystemWatcherया एक टाइमर पर मतदान के लिए सबसे अच्छा विकल्प होगा। मैंने अतीत में दोनों तरीकों का इस्तेमाल किया है, लेकिन बड़े पैमाने पर नहीं।

क्या मुद्दे (प्रदर्शन, विश्वसनीयता आदि) या तो विधि के साथ हैं?

Comments

FileSystemWatcher एक टपका हुआ अमूर्त है और कुछ भी लेकिन सबसे बुनियादी मामलों पर भरोसा नहीं किया जा सकता है। यहां देखें: stackoverflow.com/a/22768610/129130

— स्टीन

FileSystemWatcher की विश्वसनीयता के विषय पर रेमंड चेन (Microsoft विशेषज्ञ) द्वारा इस उत्तर के संदर्भ के लिए एक लिंक जोड़ना चाहते हैं । और उनका ब्लॉग: द ओल्ड न्यू थिंग (उदाहरण के लिए FileSystemWatcher की खोज)।

— Stein Stesmul

Answer 1

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

संपादित करें: यदि आपके पास UI है, तो आप अपने उपयोगकर्ता को मतदान के बजाय परिवर्तनों के लिए "ताज़ा" करने की क्षमता दे सकते हैं। मैं इसे एक फाइल सिस्टम वॉचर के साथ जोड़ूंगा।

Comments

मैंने देखा है अगर नीचे गिर, भी। हमने जो समाधान उपयोग किया है वह हमारी अपनी कक्षा को चारों ओर से लपेटने के लिए है, जहां रैपर वर्ग ALSO इस अवसर पर जांचने के लिए टाइमर का उपयोग करता है कि चौकीदार अभी भी जा रहा है।

— जोएल कोएहॉर्न

हम ऐसा ही कुछ करते हैं - एक बार जब हमने फाइलसीटर्ड इवेंट में फाइल को संसाधित कर लिया है, तो हम लौटने से पहले किसी भी अन्य नई फ़ाइलों के लिए मैन्युअल जांच करते हैं। ऐसा लगता है कि एक साथ आने वाली बहुत सारी फ़ाइलों के साथ होने वाली किसी भी समस्या को कम करना है।

— जॉन सोबेल

मेरा मानना ​​है कि हमने एक स्थानीय निर्देशिका और एक फ़ाइल साझा पर XP और सर्वर 2003 में इसका परीक्षण किया था, और क्षेत्र में XP मशीनें थीं। हमें स्थानीय dir और फ़ाइल शेयर दोनों के साथ समस्या थी। जिन संभावित कारणों के साथ हम आए थे, उनमें से एक निर्देशिका में कुछ ही समय में बहुत सी फाइलों की कॉपी / निर्माण था।

— जेसन जैक्सन

यह बहुत रचनात्मक और न ही केवल राज्य के लिए profesional "मैंने एक दिन एक भूत देखा है"। ऐसा लगता है कि लोग थ्रेड डाउन करते हैं, नॉन-पेज-आउटबल बफर ओवररन के बारे में एमएसडीएन दस्तावेज़ का उल्लेख करना आपकी समस्याओं को समझा सकता है। क्या आपने ब्रेंट के दृष्टिकोण का उपयोग करने की कोशिश की है?

— v.oddou

मैंने अभी अमेज़ॅन पर एक गैस सेंसर खरीदा है और इसने मुझे चकित कर दिया है कि कितने लोगों ने कहा कि यह काम नहीं करता है, जब वे स्पष्ट रूप से इसे सही ढंग से कैलिब्रेट नहीं करते थे या अंशांकन के बारे में भी नहीं जानते थे ... FileSystemWatcher ने उच्च ट्रैफ़िक के साथ सीमाएं जानी हैं इसका बफर आकार। लगभग गारंटी है कि इसका कारण "विफल" है। यह आसानी से प्रलेखन में समझाया गया है और ऐसे काम हैं जो बहुत विश्वसनीय संचालन प्रदान करते हैं (जैसा कि नीचे पोस्ट किया गया है)। यह सिर्फ "इर्रर, कुछ करने के लिए एक अच्छा जवाब नहीं है, जो एक बार काम नहीं करता है, निश्चित रूप से क्यों ... किसी को भी इस पर भरोसा नहीं करना चाहिए"।

— u8it

Answer 2

मेरे पास सबसे बड़ी समस्या है फाइलें गुम होना जब बफर पूरा हो जाता है। पाई को ठीक करने के लिए आसान है - बस बफर बढ़ाएं। याद रखें कि इसमें फ़ाइल नाम और ईवेंट शामिल हैं, इसलिए इसे फ़ाइलों की अपेक्षित मात्रा (परीक्षण और त्रुटि) तक बढ़ाएं। यह स्मृति का उपयोग करता है जिसे पृष्ठांकित नहीं किया जा सकता है, इसलिए यदि स्मृति कम हो जाती है तो यह अन्य प्रक्रियाओं को पृष्ठ पर लाने के लिए बाध्य कर सकती है।

यहाँ बफर पर MSDN लेख है: FileSystemWatcher .. ::। आंतरिक संपत्ति

प्रति MSDN:

बफर का आकार बढ़ाना महंगा है, क्योंकि यह नॉन पेजेड मेमोरी से आता है जिसे डिस्क पर स्वैप नहीं किया जा सकता है, इसलिए बफर को जितना संभव हो उतना छोटा रखें। एक बफर अतिप्रवाह से बचने के लिए, अवांछित परिवर्तन सूचनाओं को फ़िल्टर करने के लिए NotifyFilter और InceSubdirectories गुणों का उपयोग करें।

हम एक समय में एक बड़े बैच की उम्मीद के कारण 16 एमबी का उपयोग करते हैं। ठीक काम करता है और कभी कोई फाइल मिस नहीं करता है।

हम प्रक्रिया शुरू करने से पहले सभी फाइलों को एक बार भी पढ़ते हैं ... सुरक्षित रूप से कैश की गई फ़ाइल नाम प्राप्त करें (हमारे मामले में, डेटाबेस तालिका में) फिर उन्हें संसाधित करें।

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

Comments

बफर का उमड़ना? ओह, आपका मतलब स्टैक ओवरफ्लो है।

— TheFlash

.NET 3.5 के अनुसार: "आप बफर को 4 KB या उससे अधिक पर सेट कर सकते हैं, लेकिन यह 64 KB से अधिक नहीं होना चाहिए"

— ब्रैड करें

अगर आप 16 एमबी का उपयोग कर रहे हैं, तो फाइलसिस्टमवॉकर के लिए अधिकतम आंतरिक बफर 64KB है?

— BK

@ जार्विस, एक बफर एक टेम्परेरी स्टोरेज लोकेशन है जिसे सूचनाओं को रखने के लिए कॉन्फ़िगर किया गया है क्योंकि इसे तब तक प्रसारित किया जाता है जब तक इसे संसाधित नहीं किया जा सकता है, इसका मतलब आमतौर पर एक FIFO या कतार है जैसा कि आप अनुरोधों से निपटने के लिए चाहते हैं, जबकि वे कुछ प्रक्रियाओं में पहुंचते हैं जैसे कि कार्यक्रमों में पुनरावृत्ति एक फिल्म या स्टैक संरचना का उपयोग किया जाता है, इस मामले में हम निश्चित रूप से घटना कतार बफ़र का उल्लेख कर रहे हैं न कि कार्यक्रमों को स्टैक बफर कहते हैं

— माइक टीटी

petermeinl.wordpress.com/2015/05/18/tamed-filesystemwatcher यह पोस्ट वास्तविक विश्व अनुप्रयोगों में फ़ाइल सिस्टम की निगरानी के लिए इसका उपयोग करते समय सामान्य रूप से सामना करने वाली मानक FileSystemWatcher (FSW) समस्याओं के बारे में मजबूत आवरण साझा करता है।

— किनिकेत

Answer 3

FileSystemWatcherभी, व्यस्त समय के दौरान परिवर्तनों को अनदेखा कर सकते हैं पंक्तिबद्ध परिवर्तन की संख्या प्रदान की बफर overflows है। यह प्रति वर्ग .NET .NET की सीमा नहीं है, लेकिन अंतर्निहित Win32 बुनियादी ढांचे की है। हमारे अनुभव में, इस समस्या को कम करने का सबसे अच्छा तरीका है कि सूचनाओं को जितनी जल्दी हो सके उतारा जाए और दूसरे धागे पर उनके साथ व्यवहार किया जाए।

जैसा कि ऊपर @ChillTemp द्वारा उल्लेख किया गया है, चौकीदार गैर-विंडोज शेयरों पर काम नहीं कर सकता है। उदाहरण के लिए, यह माउंटेड नोवेल ड्राइव पर बिल्कुल भी काम नहीं करेगा।

मैं इस बात से सहमत हूं कि एक अच्छा समझौता किसी भी छूटे हुए बदलाव को लेने के लिए एक सामयिक चुनाव करना है।

Comments

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

— ब्रेंट रॉकवुड

Answer 4

यह भी ध्यान दें कि फ़ाइल सिस्टम वॉचर फ़ाइल शेयरों पर विश्वसनीय नहीं है। विशेष रूप से यदि फ़ाइल साझा गैर-विंडोज़ सर्वर पर होस्ट की जाती है। एफएसडब्ल्यू का उपयोग किसी भी महत्वपूर्ण चीज के लिए नहीं किया जाना चाहिए। या यह सत्यापित करने के लिए एक सामयिक सर्वेक्षण के साथ प्रयोग किया जाना चाहिए कि यह कुछ भी याद नहीं है।

Comments

क्या Microsoft ने स्वीकार किया है कि यह गैर-विंडोज़ फ़ाइल शेयरों पर विश्वसनीय नहीं है? विंडोज शेयर से लिनक्स आधारित एसएमबी शेयर पर स्विच करने के बाद से हम निश्चित रूप से इस पहले हाथ का अनुभव कर रहे हैं।

— शॉन

यह नही है कि मैं जानता हूँ। और मुझे यकीन है कि यह बस विभिन्न विक्रेताओं के बीच एक दोषपूर्ण खेल होगा।

— चिल्लेम्प

हमने मैप किए गए ड्राइव पर फ़ाइल सिस्टम वॉचर के साथ समस्याओं का अनुभव किया है। यदि नक्शा डिस्कनेक्ट हो जाता है और फिर फ़ाइल वॉकर को फिर से जोड़ देता है तो परिवर्तन नहीं होता है। आसानी से हल हो गया है, लेकिन अभी भी फ़ाइल सिस्टम वॉचर IMHO के खिलाफ एक हड़ताल।

— रिचर्ड डोरमैन

Answer 5

व्यक्तिगत रूप से, मैंने FileSystemWatcherएक उत्पादन प्रणाली का उपयोग किया है, और यह ठीक काम किया है। पिछले 6 महीनों में, इसमें 24x7 चलने वाली एक भी हिचकी नहीं थी। यह एकल स्थानीय फ़ोल्डर (जो साझा किया गया है) की निगरानी कर रहा है। हमारे पास फ़ाइल संचालन की अपेक्षाकृत कम संख्या है जिसे इसे संभालना पड़ता है (प्रति दिन 10 घटनाओं को निकाल दिया जाता है)। यह ऐसा कुछ नहीं है जिसके बारे में मुझे कभी चिंता हुई हो। यदि मुझे निर्णय का रीमेक करना होता तो मैं इसे फिर से इस्तेमाल करता।

Answer 6

मैं वर्तमान में FileSystemWatcherहर 100 मिलीसेकंड पर औसत रूप से अपडेट की जा रही एक्सएमएल फाइल पर इस्तेमाल करता हूं ।

मैंने पाया है कि जब तक FileSystemWatcherठीक से कॉन्फ़िगर किया गया है तब तक आपको कभी भी स्थानीय समस्याओं का सामना नहीं करना चाहिए फ़ाइलों के ।

मुझे दूरस्थ फ़ाइल देखने और गैर-विंडोज शेयरों पर कोई अनुभव नहीं है।

जब तक आप स्वाभाविक रूप से अविश्वास नहीं करते FileSystemWatcherया हर किसी ने यहां सूचीबद्ध (गैर-विंडोज शेयर, और रिमोट फ़ाइल देखने) सूचीबद्ध किया है, तब तक मैं फ़ाइल को अतिरेक और ओवरहेड के लायक नहीं मानूंगा ।

Answer 7

मैं मतदान के साथ जाऊंगा।

नेटवर्क समस्याएँ FileSystemWatcherअविश्वसनीय होने का कारण बनती हैं (भले ही त्रुटि ईवेंट को ओवरलोड करते समय)।

Answer 8

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

Comments

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

— मोसे बोताकिनी

Answer 9

मुझे नेटवर्क ड्राइव पर FSW के साथ कुछ बड़ी समस्याएं थीं: किसी फ़ाइल को हमेशा हटाना त्रुटि घटना, कभी नहीं हटाए गए इवेंट। मुझे कोई हल नहीं मिला, इसलिए मैं अब FSW से बचता हूं और मतदान का उपयोग करता हूं।

दूसरी ओर निर्माण की घटनाओं ने ठीक काम किया, इसलिए यदि आपको केवल फ़ाइल निर्माण के लिए देखने की आवश्यकता है, तो आप एफएसडब्ल्यू के लिए जा सकते हैं।

इसके अलावा, मुझे स्थानीय फ़ोल्डरों पर कोई समस्या नहीं थी, चाहे कोई भी साझा या न हो।

Answer 10

जितनी जल्दी हो सके घटना विधि से लौटकर, एक और धागे का उपयोग करके, मेरे लिए समस्या का समाधान किया:

private void Watcher_Created(object sender, FileSystemEventArgs e)
{
    Task.Run(() => MySubmit(e.FullPath));
}

Answer 11

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

वर्तमान में, मैं यह तय करने की कोशिश कर रहा हूं कि मैं जिस परियोजना का विकास कर रहा हूं, उसके लिए मैं एफएसडब्ल्यू का उपयोग करूंगा या मतदान करूंगा। उत्तरों को पढ़ना, यह स्पष्ट है कि ऐसे मामले हैं जहां एफएसडब्ल्यू पूरी तरह से जरूरतों को कवर करता है, जबकि अन्य समय में आपको मतदान की आवश्यकता होती है । दुर्भाग्य से, कोई जवाब वास्तव में प्रदर्शन अंतर (यदि कोई है) से निपटा है, केवल "विश्वसनीयता" मुद्दों के साथ। क्या कोई ऐसा है जो सवाल के उस हिस्से का जवाब दे सकता है?

EDIT: FSW और मतदान दोनों का उपयोग करने की वैधता के लिए nmclean का बिंदु (आप टिप्पणियों में चर्चा पढ़ सकते हैं, यदि आप रुचि रखते हैं) एक बहुत ही तर्कसंगत स्पष्टीकरण प्रतीत होता है कि ऐसी परिस्थितियां क्यों हो सकती हैं जो FSW और मतदान दोनों का उपयोग कर रही है कुशल। उस पर प्रकाश डालने के लिए धन्यवाद (मेरे लिए और किसी के पास भी यही राय है), nmclean ।

Comments

क्या होगा यदि आप जितनी जल्दी हो सके फ़ाइल परिवर्तनों का जवाब देना चाहते हैं? यदि आप उदाहरण के लिए प्रति मिनट एक बार मतदान करते हैं, तो हो सकता है कि फ़ाइल बदलने और आपके आवेदन में परिवर्तन के बीच 1 मिनट की देरी हो। एफएसडब्ल्यू घटना संभवतः उससे पहले ही ट्रिगर हो जाएगी। इसलिए आप दोनों का उपयोग करके घटनाओं को जितना हो सके उतना कम देरी से संभाल रहे हैं, लेकिन यदि कोई भी हो तो छूटी हुई घटनाओं को उठा सकते हैं।

— rom99

@ rom99 बिल्कुल मेरी बात। यदि एफएसडब्ल्यू उन मामलों में अविश्वसनीय है जिन्हें आपको त्वरित प्रतिक्रिया की आवश्यकता है, तो इसका उपयोग करने का कोई मतलब नहीं है, क्योंकि आपके पास ऐसे मामले होंगे जहां कोई त्वरित प्रतिक्रिया नहीं होगी, इस प्रकार, आपका आवेदन अविश्वसनीय होगा। छोटे अंतराल में, एक धागे में मतदान, वह होगा जो आपको करने की आवश्यकता है। ऐसा करने से दोनों , साधन आपको लगता है कि मतदान कवर, हां, तो केवल मतदान का उपयोग क्यों नहीं प्रतिक्रिया समय में एक सहनशीलता होती है?

— थंडरग्रो

@ThunderGr "इस प्रकार, आपका आवेदन अविश्वसनीय होगा।" - कई मामलों में, विश्वसनीयता के लिए गति एक शर्त नहीं है। काम तो करना ही चाहिए , लेकिन यह थोड़ी देर इंतजार कर सकता है। यदि हम धीमी, विश्वसनीय मतदान को तेज, अविश्वसनीय एफएसडब्ल्यू के साथ जोड़ते हैं , तो हमें एक ऐसा आवेदन मिलता है जो हमेशा विश्वसनीय और कभी-कभी तेज होता है, जो विश्वसनीय और तेज से बेहतर है। हम एफएसडब्ल्यू को हटा सकते हैं और लगातार मतदान करके उसी अधिकतम प्रतिक्रिया समय को प्राप्त कर सकते हैं, लेकिन यह बाकी एप्लिकेशन की जवाबदेही की कीमत पर है, इसलिए केवल तभी किया जाना चाहिए जब तत्काल प्रतिक्रिया की आवश्यकता हो।

— nmclean

अब उपरोक्त एक गरीब तर्क क्यों है? क्योंकि, हालांकि हमें अभी भी डिस्क एक्सेस की आवश्यकता है, हमें इसकी आवश्यकता कम है । इसी तरह, आप कम मतदान कर सकते हैं। सिर्फ इसलिए कि हम अभी भी सभी फाइलों की जांच करते हैं, इसका मतलब यह नहीं है कि कार्यभार समान है। आपका कथन, "FSW के साथ सीपीयू समय पर मतदान महंगा है या नहीं," गलत है । FSW के लिए "immediacy" चिंता को उतारने से, हम मतदान को एक निष्क्रिय, निम्न-प्राथमिकता वाले कार्य में बदल सकते हैं , जैसे कि किसी भी समय आवेदन की व्यस्तता बहुत कम हो जाती है जबकि अभी भी immediacy का "उपचार" प्रदान करता है। आप केवल मतदान के साथ ही शेष राशि प्राप्त नहीं कर सकते।

— nmclean

@nmclean आपके द्वारा किए गए तरीके को स्पष्ट करने के लिए समय और ऊर्जा लेने के लिए धन्यवाद। जब आप इसे इस तरह से लगाते हैं, तो यह निश्चित रूप से बहुत मायने रखता है। जैसे कई बार ऐसा होता है कि कैश आपकी विशिष्ट समस्या के लिए उपयुक्त नहीं है, इसलिए FSW (जब यह अविश्वसनीय साबित होता है) उपयुक्त नहीं हो सकता है। यह पता चला है कि आप सभी के साथ सही थे। मुझे खेद है कि मुझे इसे प्राप्त करने में इतना समय लगा।

— थंडरग्रास

Answer 12

परिवर्तन के बजाय ईवेंट बनाने के साथ काम करने का समाधान

यहां तक ​​कि कॉपी, कट, पेस्ट, चाल के लिए भी।

class Program
{        

        static void Main(string[] args)
        {
            string SourceFolderPath = "D:\\SourcePath";
            string DestinationFolderPath = "D:\\DestinationPath";
            FileSystemWatcher FileSystemWatcher = new FileSystemWatcher();
            FileSystemWatcher.Path = SourceFolderPath;
            FileSystemWatcher.IncludeSubdirectories = false;
            FileSystemWatcher.NotifyFilter = NotifyFilters.FileName;   // ON FILE NAME FILTER       
            FileSystemWatcher.Filter = "*.txt";         
             FileSystemWatcher.Created +=FileSystemWatcher_Created; // TRIGGERED ONLY FOR FILE GOT CREATED  BY COPY, CUT PASTE, MOVE  
            FileSystemWatcher.EnableRaisingEvents = true;

            Console.Read();
        }     

        static void FileSystemWatcher_Created(object sender, FileSystemEventArgs e)
        {           
                string SourceFolderPath = "D:\\SourcePath";
                string DestinationFolderPath = "D:\\DestinationPath";

                try
                {
                    // DO SOMETING LIKE MOVE, COPY, ETC
                    File.Copy(e.FullPath, DestinationFolderPath + @"\" + e.Name);
                }
                catch
                {
                }          
        }
}

इस फ़ाइल द्रष्टा के लिए समाधान जबकि फ़ाइल विशेषता परिवर्तन घटना स्थिर भंडारण का उपयोग कर

class Program
{
    static string IsSameFile = string.Empty;  // USE STATIC FOR TRACKING

    static void Main(string[] args)
    {
         string SourceFolderPath = "D:\\SourcePath";
        string DestinationFolderPath = "D:\\DestinationPath";
        FileSystemWatcher FileSystemWatcher = new FileSystemWatcher();
        FileSystemWatcher.Path = SourceFolderPath;
        FileSystemWatcher.IncludeSubdirectories = false;
        FileSystemWatcher.NotifyFilter = NotifyFilters.LastWrite;          
        FileSystemWatcher.Filter = "*.txt";         
        FileSystemWatcher.Changed += FileSystemWatcher_Changed;
        FileSystemWatcher.EnableRaisingEvents = true;

        Console.Read();
    }     

    static void FileSystemWatcher_Changed(object sender, FileSystemEventArgs e)
    {
        if (e.Name == IsSameFile)  //SKIPS ON MULTIPLE TRIGGERS
        {
            return;
        }
        else
        {
            string SourceFolderPath = "D:\\SourcePath";
            string DestinationFolderPath = "D:\\DestinationPath";

            try
            {
                // DO SOMETING LIKE MOVE, COPY, ETC
                File.Copy(e.FullPath, DestinationFolderPath + @"\" + e.Name);
            }
            catch
            {
            }
        }
        IsSameFile = e.Name;
    }
}

एकाधिक ट्रिगरिंग ईवेंट की इस समस्या के लिए यह समाधान समाधान है।

Answer 13

मैं कहता हूं कि मतदान का उपयोग करें, विशेष रूप से एक टीडीडी परिदृश्य में, क्योंकि फाइलों की उपस्थिति का मजाक उड़ाना / रोकना बहुत आसान है, अन्यथा जब मतदान की घटना को अधिक "अनियंत्रित" fsw घटना पर भरोसा करने के लिए ट्रिगर किया जाता है। + कि कई क्षुधा पर काम किया है, जो fsw त्रुटियों से ग्रस्त थे।