नोड.जेएस में, क्या यह बताना संभव है कि एक देखी गई फ़ाइल को स्थानांतरित किया गया था?

Question

fs.watch केवल दो संभावित घटना प्रकार प्रदान करता है: 'rename' और 'change'। 'rename' ईवेंट की रिपोर्ट करने के लिए fs.watch का कारण बनने के लिए दोनों फ़ाइल का नाम बदलना (उदा।

फ़ाइल को स्थानांतरित करने के बाद, fs.watch इसकी घटनाओं की रिपोर्ट करना जारी रखेगा (जब तक कि आप स्पष्ट रूप से FSWatcher को बंद न करें)। जब ऐसा होता है, तो मैं जानना चाहता हूं कि फ़ाइल कहां स्थानांतरित हो गई है।

क्या ऐसा करने का कोई तरीका है, सिस्टम पर हर फ़ाइल को छूने से कम यह देखने के लिए कि 'change' ईवेंट कब निकाल दिया गया है?

Answer 1

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

इस पर एक कार्यवाही fs.link के माध्यम से लक्ष्य फ़ाइल के लिए अस्थायी हार्ड लिंक बनाना होगा, फिर आप परिवर्तन के बाद भी फ़ाइल पर जा सकते हैं, हालांकि आप इसका नया नाम पुनर्प्राप्त नहीं कर पाएंगे।

यह दिलचस्प है कि EventMachine एक ही मुद्दा है: http://eventmachine.rubyforge.org/EventMachine/FileWatch.html#M000291

Answer 2

मुझे लगता है कि आप फ़ाइल के मूल स्टेट को देखो और inode जो फ़ाइल के पहचानकर्ता है देखने के लिए होगा। अगर फ़ाइल एक विभाजन/फाइल सिस्टम/ड्राइव से दूसरे में नहीं चली गई (जो वास्तव में एक कॉपी-अप-डिलीट-मूल ऑपरेशन होना चाहिए), तो inode वही होगा।

दुर्भाग्यवश, आमतौर पर inode एस की कोई लुकअप तालिका नहीं है, ताकि उनका नया नाम/स्थान प्राप्त हो सके। आपको पूरी प्रणाली को व्यवस्थित रूप से खोजना होगा, जो शायद इतना बुरा नहीं हो सकता है कि आप पहले संभावित स्थानों को देख सकते हैं। या यदि आप केवल सीमित क्षेत्र की खोज कर सकते हैं।

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

यदि केवल हैं, तो इस क्षेत्र में कुछ हज़ार फाइलें कहें, यहां पर समाधान बहुत अच्छी तरह से काम करना चाहिए, यदि आपके सिस्टम के आधार पर और अधिक है, तो यह काम कर सकता है, लेकिन देरी हो सकती है।

यदि आप देरी को कम करना चाहते हैं, तो आपके पास फाइलों का एक SQL डेटाबेस हो सकता है जिसे आप पहले ही inode एस के बारे में जानते हैं। उदाहरण के लिए, /folder/filea और /folder/fileb दोनों अलग-अलग inode एस के साथ मौजूद हैं। जब filebfilec पर ले जाया गया है, तो आपको statfileainode की तलाश करने की आवश्यकता नहीं है क्योंकि आप पहले से ही इसे पहले देख चुके हैं। इस तर्क को नाटकीय रूप से stat आदेशों की संख्या को कम करना चाहिए। हालांकि, अगर filea हटा दिया गया है और filebfilea की जगह में स्थानांतरित किया गया है, तो इस नाटकीय कमी विधि को कोई परिणाम नहीं मिलेगा, इस मामले में आपको पूरी कार्य निर्देशिका खोजने के लिए वापस गिरना होगा।

आपके पास अभी भी यह सुनिश्चित करने का विकल्प है कि ओएस फ़ोल्डर्स /etc या /dev जैसे हैं। केवल अंतिम उपाय के रूप में उपयोग किया जाता है।जिसे आप कभी भी खोजना नहीं चाहते हैं, मानते हैं कि आप अस्थायी हार्ड लिंक का उपयोग करके हटाना का पता लगा सकते हैं।

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