यह पता लगाना कि फ़ाइल.मोव को 'कॉपी -> डिलीट' की आवश्यकता होगी या फ़ाइल सिस्टम टेबल

Question

अस्वीकरण: मैं तुरंत स्वीकार करूंगा कि फाइल सिस्टम कैसे काम करता है, इस बारे में विवरण के बारे में मुझे अज्ञानता की उचित मात्रा है। मैं इतने लंबे समय तक एनटीएफएस का उपयोग कर रहा हूं कि मैंने जो व्यवहार देखा है, उसके साथ-साथ जो भी मैंने इंटरनेट पर डोरकिंग से सीखा है, उसके बारे में बता रहा हूं - हालांकि ...

मैं उम्मीद कर रहा था कि वहां है यह पता लगाने का एक तरीका है कि 'स्थान ए' से 'स्थान बी' तक फ़ाइल को स्थानांतरित करते समय, क्या ऑपरेशन को 'File.Copy -> File.Delete' के बराबर की आवश्यकता होगी या यदि यह वास्तविक फ़ाइल डेटा की प्रतिलिपि नहीं करेगा, लेकिन बस 'मास्टर फ़ाइल टेबल' या जैसे स्थान में स्थान अपडेट करें।

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

मुझे एहसास है कि जब मैं File.Move को कॉल करता हूं और एक डिस्क/विभाजन पर किसी स्थान से फ़ाइल को स्थानांतरित करता हूं, तो फ़ंक्शन को डिस्क/विभाजन के बीच प्रभावी रूप से फ़ाइल डेटा कॉपी करना होगा। जब यह इस स्थिति से मुकाबला करता है, तो मैं यह पता लगाने में सक्षम होना चाहता हूं कि ऐसा होगा इसलिए मैं कोड का उपयोग कर सकता हूं जिसे मैंने लिखा है जो फ़ाइल की प्रतिलिपि बनायेगा और विस्तृत प्रगति रिपोर्टिंग देगा क्योंकि बाइट्स को स्थानांतरित किया जाता है, इसलिए मैं अक्सर UI में प्रगति बार अपडेट कर सकता हूं।

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

.NET 4 (सी #) का उपयोग करना, क्या अन्य माध्यमों के माध्यम से पता लगाना संभव है कि फ़ाइल को कॉल करना है या नहीं। किसी भी 'कॉपी -> डिलीट' ऑपरेशन की आवश्यकता होगी या फ़ाइल तालिका को अपडेट नहीं करेगा और फ़ाइल डेटा कॉपी नहीं करेगा ?

संपादित करें:

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

नोट - प्रोग्राम नेटवर्क यूएनसी पथ का उपयोग कर सकता है जो एक ही रूट पथ के साथ विभिन्न भौतिक डिस्क का उपयोग कर सकता है यानी: \\ somename \ share \ workfolder \ project एक अलग भौतिक डिस्क पर हो सकता है \\ somename \ शेयर \ workfoldder \ otherproject। तो मुझे एक ही डिस्क/विभाजन पर एक स्रोत और गंतव्य फ़ोल्डर देखने के लिए विभाजन आईडी या भौतिक डिस्क आईडी का पता लगाने के लिए एक विधि की आवश्यकता होगी।

धन्यवाद

Answer 1

आप हमेशा 0/MoveFileWithProgress पर पी/आमंत्रित कर सकते हैं। एक सरसरी पढ़ने से, ऐसा लगता है कि स्थानांतरित होने के बजाए फ़ाइल कॉपी होने पर यह आपको अधिक बारीकी से प्रगति देगा।

वैकल्पिक रूप से, हमेशा SHFileOperation है, जो आपको विंडोज एक्सप्लोरर यूआई और सेमेन्टिक्स देगा।

Answer 2

मुझे नहीं लगता कि आप के रूप में आप देखभाल करने के लिए नहीं करना पड़ेगा एक सामान्य तरीके से ऐसी बात का पता लगा सकते हैं। यदि आप इसका परीक्षण कर सकते हैं, तो क्या होगा और अन्यथा यह होगा कि इस से कोई ज्ञान निकाला जा सकता है (स्थानांतरण की गति को छोड़कर)।

.net में फ़ाइल सिस्टम को सारणीबद्ध किया गया है ताकि आप फ़ाइलों को एक स्थान से दूसरे स्थान पर ले जा सकें, यह जानने के बिना कि आप किस विभाजन/फाइल सिस्टम/नेटवर्क ड्राइव से प्रतिलिपि बना रहे हैं।

अपनी विशिष्ट समस्या के लिए, आप हमेशा प्रगति पट्टी क्यों नहीं दिखाते हैं और इसे दोनों मामलों के लिए एक निश्चित अंतराल पर अद्यतन किया है।

Answer 3

जबकि 100% सही नहीं है (सिम-लिंक इसे चीजों की तरह दिखते हैं, वे एक बड़े विभाजन होते हैं जबकि वे अलग-अलग भौतिक ड्राइव हो सकते हैं (मेरे सिर के शीर्ष से डब्ल्यूएचएस व्यापक रूप से उपयोग करता है), मैं प्रगति के उद्देश्य के लिए कहूंगा बार यह मानते हुए कि एक ही विभाजन (System.IO.Path.GetPathRoot) पर रहना संभवतः पर्याप्त होगा।

Answer 4

मुझे हस्तांतरण की गति और प्रगति सलाखों की निगरानी के बारे में कुछ भी पता नहीं है लेकिन यह पता लगाने के मुद्दे के लिए कि कोई फ़ाइल है या नहीं एक अलग ड्राइव/विभाजन में जाने के लिए आप बस गंतव्य और स्रोत फ़ाइल के ड्राइव/विभाजन पत्र की तुलना कर सकते हैं ...

यदि आप File.Move के लिए पूर्ण पथ का उपयोग कर रहे हैं तो आप कुछ सरल के रूप में उपयोग कर सकते हैं :

if(sourcePath[0]!=destinationPath[0]) 
    //enable transfer speed monitoring 

यदि आप संबंधित पथ आप एक छोटे से अधिक स्ट्रिंग पथ की व्याख्या के साथ गंतव्य/स्रोत ड्राइव/विभाजन को निकालने के लिए की जरूरत का उपयोग कर रहे हैं।

मुझे खेद है कि मेरा समाधान बहुत आसान है या यदि मुझे कोई अन्य समस्या नहीं दिखाई दे रही है।

Answer 5

मुझे पूरा यकीन है कि आप यह नहीं कर सकते हैं।

एनटीएफएस पर भी शुरुआत करने वालों के लिए स्थानीय ड्राइव के लिए ड्राइव लेटर को देखकर पर्याप्त नहीं है क्योंकि you can mount a drive inside an empty folder on an existing drive है। इसका मतलब है कि भले ही दोनों पथों में एक ही ड्राइव अक्षर हो, फिर भी वे अलग-अलग डिस्क पर आरोहित हो सकते हैं।

इसे एक और कदम लेने के लिए बाहरी शेयरों पर विचार करें, संभवतः एक * निक्स आधारित प्रणाली पर लगाए गए और सांबा के माध्यम से उजागर किए गए। * निक्स प्रतीकात्मक लिंक यह बताते हुए असंभव बनाते हैं कि दो पथ एक ही भौतिक डिवाइस पर अकेले पथ देखकर रहते हैं - एकमात्र विकल्प रिमोट मशीन से पूछताछ करना होगा "क्या ये दो पथ एक ही ड्राइव पर मौजूद हैं?", जो कुछ मुझे बहुत संदेह होगा।

मैं केवल File.Move का उपयोग करता हूं और स्वीकार करता हूं कि आपको प्रगति अपडेट नहीं मिलते हैं। अपनी खुद की प्रतिलिपि कार्यान्वयन लिखना मुझे किसी भी तरह से "विशेष रूप से अच्छा विचार नहीं" के रूप में हमला करता है।

Answer 6

आप GetFileInformationByHandle() फ़ंक्शन को P/आमंत्रित कर सकते हैं, जो वॉल्यूम सीरियल नंबर देता है। यदि वॉल्यूम सीरियल नंबर दोनों फाइलों के लिए समान है, तो वे एक ही वॉल्यूम पर हैं और कोई कॉपी-एंड-डिलीट आवश्यक नहीं होगा।