क्या यह जांचने के लिए हर एक बाइट को पढ़ना आवश्यक है कि क्या एक कॉपी की गई फाइल मूल के समान है?

Question

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

मेरा प्रश्न है: क्या यह आवश्यक है? क्या सीआरसी या ऐसी कोई तकनीक गलत हो सकती है? क्या आपको एक प्रोग्रामर के रूप में इस सही लेकिन धीमी प्रणाली को लागू करने और लागू करने की कोशिश करनी चाहिए, या क्या यह बहुत चरम है?

Comments

"Rsync" इसे कैसे संभालता है, इस पर एक नज़र डालें।

दोनों फाइलों पर CRCs (या, बेहतर, sha1sums) की गणना करना वैसे भी हर बाइट को पढ़ने की आवश्यकता है। यदि आप एक बाइट-बाय-बाइट तुलना करते हैं, तो आप जैसे ही मिसमैच देखते हैं, वैसे ही छोड़ सकते हैं - और आपको दो अलग-अलग फ़ाइलों के बारे में चिंता करने की ज़रूरत नहीं है जो एक ही चेकसम की होती हैं (हालांकि यह शमसम के लिए गायब होने की संभावना नहीं है) । दूसरी ओर, जब आप एक ही मशीन पर नहीं हैं फ़ाइलों की तुलना कर रहे हैं, तब चेकसम तुलना उपयोगी होती है; चेकसम स्थानीय रूप से गणना की जा सकती है, और आपको नेटवर्क पर संपूर्ण सामग्री को स्थानांतरित करने की आवश्यकता नहीं है।

— कीथ थॉम्पसन

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

— कीथ थॉम्पसन

@KeithThompson: मुझे लगता है कि आपकी पहली टिप्पणी का जवाब होना चाहिए :-)

— डीन हार्डिंग

संक्षिप्त उत्तर - नहीं, यह आपके कंप्यूटर को आपके लिए करने के लिए सबसे अच्छा है।

— Psr

Answer 1

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

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

हाइब्रिड दृष्टिकोण भी संभव हैं। उदाहरण के लिए, आप एक बार में दो फ़ाइलों के लिए चेकसम की गणना और तुलना कर सकते हैं, जो पूरी फ़ाइलों ( यदि वे भिन्न हैं) को पढ़ने से बच सकते हैं, जबकि पूरे नेटवर्क में संपूर्ण फ़ाइल को प्रसारित करने से भी बच सकते हैं। Rsync प्रोटोकॉल कुछ इस तरह से करता है।

ध्यान दें कि एक साधारण सीआरसी का उपयोग करने से आपको टक्कर का एक उचित मौका मिलता है, जैसा कि डेव रैगर ने अपने उत्तर में उल्लेख किया है। कम से कम sha1sum का उपयोग करें , या हाल ही में कुछ और भी। (अपने स्वयं के हैशिंग एल्गोरिथ्म का आविष्कार करने की कोशिश न करें; जो लोग sha1sum विकसित करते हैं वे इस सामान के बारे में हम दोनों में से कहीं अधिक जानते हैं।)

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

यहां एक उदाहरण दिया गया है जिससे आपको अंदाजा हो सकता है कि SHA-1 टक्कर लेने में क्या होगा। यदि पृथ्वी पर सभी 6.5 बिलियन मानव प्रोग्रामिंग कर रहे थे, और हर दूसरे, हर एक कोड का उत्पादन कर रहा था जो पूरे लिनक्स कर्नेल इतिहास (1 मिलियन गिट ऑब्जेक्ट) के बराबर था और इसे एक विशाल गिट रिपॉजिटरी में धकेल दिया, तो 5 साल तक लगेंगे उस भंडार में एक SHA-1 ऑब्जेक्ट के टकराव की 50% संभावना होने के लिए पर्याप्त वस्तुएं थीं। एक उच्च संभावना मौजूद है कि आपकी प्रोग्रामिंग टीम के प्रत्येक सदस्य को उसी रात असंबंधित घटनाओं में भेड़ियों द्वारा हमला और मार दिया जाएगा।

सारांश :

बाइट-दर-बाइट तुलना स्थानीय तुलना के लिए अच्छी है। sha1sum रिमोट तुलना के लिए अच्छा है, और झूठी सकारात्मकता का कोई महत्वपूर्ण मौका नहीं देता है।

Comments

यह ध्यान दिया जाना चाहिए कि एक "अच्छे" हैश फ़ंक्शन की सामान्य परिभाषा में संपत्ति शामिल है कि एक ही हैश ("टकराव-प्रतिरोध") के साथ विभिन्न इनपुट बनाने के लिए बहुत कठिन है। SHA-1 में इस संबंध में कुछ (अभी तक सैद्धांतिक) कमजोरियां हैं, लेकिन आप "दो फाइलें जो आपस में टकराती हैं" का निर्माण नहीं कर सकते, भले ही आप काफी प्रयास करें।

— सालेके

@ स्केलेक: अपडेट किया गया

— कीथ थॉम्पसन

@KeithThompson मैं उत्तर को बढ़ा रहा हूं, लेकिन मुझे लगता है कि यह SHA1 - SHAPening

— K.Steff

मुझे संदेह है कि अगर आप GitHub पर इस सैद्धांतिक रिपो की मेजबानी करने की कोशिश करते हैं तो वे क्रेंकी हो जाएंगे।

— hBy2Py

मेरा मतलब है कि वे उन पर डेटा के प्रति सेकंड कई exabytes हालांकि दुखी होगा। :-)

— hBy2Py

Answer 2

यहाँ इसके बारे में सोचने का एक और तरीका है।

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

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

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

Answer 3

समान फ़ाइलों के लिए जाँच करने का एकमात्र सही तरीका बाइट तुलना के लिए बाइट है। निष्पक्ष सन्निकटन होने का एक और तरीका है फाइलों के लिए MD5 जैसे हैश की गणना करना और उन की तुलना करना। यह संभव है कि एक हैश टकराव हो सकता है लेकिन बहुत संभावना नहीं है।

मुझे लगता है कि जब आप तुलना कर रहे हैं तो बाइट की तुलना में बाइट की तुलना दोनों फाइलों पर हैश की गणना करने से तेज होगी। हालाँकि, यदि आपका एप्लिकेशन हैश की पूर्व-गणना करता है और आपकी फ़ाइलों के बारे में मेटा-डेटा संग्रहीत करता है, तो हैश की तुलना करना काफी तेज़ होगा।

CRC शायद जाने का रास्ता नहीं है क्योंकि यह सिर्फ एक त्रुटि का पता लगाने वाला तंत्र है, हैश नहीं। (या बहुत से संभावित टकरावों के साथ एक गरीब हैश)

Comments

+1 सहमत। यह बहुत अधिक संभावना है कि अच्छे हैशिंग फ़ंक्शन के आकस्मिक टकराव की तुलना में आपकी हार्ड ड्राइव टूट जाती है (CRC32 कमजोर है - यह भी सहमत है)।

— माइकल Micरजर

Answer 4

100% निश्चित होने के लिए दो फाइलें समान हैं, आपको वास्तव में बाइट्स की जांच करने की आवश्यकता है।

क्यों? हैश टकराव, यही कारण है कि! हैशिंग के लिए उपयोग किए गए एल्गोरिथ्म के आधार पर, टकराव कम या ज्यादा संभावित हो सकता है, लेकिन यह संभव नहीं है कि कम हो। इन चरणों का पालन करें:

1. फ़ाइल आकार की जाँच करें
2. माइम के प्रकारों की जाँच करें
3. हैश की जाँच करें
4. कुछ यादृच्छिक ऑफसेट की जाँच करें और बिट्स की तुलना करें

आपको निश्चितता की बहुत उच्च गारंटी देगा कि दो फाइलें समान हैं, हालांकि एक बहुत (अत्यंत) छोटा मौका है कि आपके हाथों पर टक्कर है। आप अपनी तुलना के साथ कितनी दूर जाना चाहते हैं इसका चुनाव स्थिति द्वारा तय किया जाएगा।

Comments

मुझे लगता है कि यदि आप एक अच्छा हैशिंग एल्गोरिथ्म चुनते हैं, तो 2. और 4. आपको कोई वास्तविक वृद्धि "समान" गुणवत्ता नहीं देंगे। शायद 1. केवल कमजोर हैश के लिए भी आवश्यक है।

— माइकल Micरजर

-1 इसका कोई मतलब नहीं है। यदि आप एक अच्छा हैशिंग एल्गोरिथ्म उठाते हैं, तो अन्य सभी चरण अतिसुधार हैं। 1. और 4. वास्तव में एक हैश द्वारा पहले से ही कवर किया गया है, और 2. बकवास है (अधिकांश फ़ाइल सिस्टम में "MIME प्रकार" की धारणा भी नहीं है, और यहां तक ​​कि अगर उनके पास था, तो यह बहुत कम जानकारी जोड़ता है)।

— सालेके

@sleske मैं फाइल के बाहर फ्लैट के बजाय कह रहा हूं, जो एक गहन संचालन है, आप कुछ प्रारंभिक ऑपरेशन कर सकते हैं जो इतने भारी नहीं हैं।

मैं सिर्फ 1 और 3 को समेटता हूं, बहुत मायने रखता है। (1) हैश की गणना की आवश्यकता को बचाते हुए विभिन्न फाइलों के अधिकांश मामलों को चिह्नित करेगा। एक ही लंबाई की फाइल पर हैश क्लैश की संभावना नहीं है इसलिए यह चिंता करने लायक नहीं है।

— माइकल शॉ

Answer 5

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

जब आपके पास सारा डेटा आसानी से उपलब्ध नहीं होता है तो वास्तव में हैशिंग चमकता है। उदाहरण के लिए, फाइलें विभिन्न मशीनों पर हैं। यह आपको गणनाओं के परिणामों को बचाने और बाद में उन्हें संदर्भित करने की भी सुविधा देता है। (क्या यह रिपोर्ट पुरानी वाली के समान है? जब आप रिपोर्ट बनाते हैं तो इसका एक हैश बचाते हैं। जब आप अगले एक को बनाते हैं तो आप बस हैश की तुलना कर सकते हैं। न केवल आपको पुराने वाले को आप में पढ़ने की आवश्यकता नहीं है। ' टी को भी इसकी एक प्रति उपलब्ध होने की आवश्यकता है।)

Answer 6

मुझे लगता है कि आपको अपने ऑपरेटिंग सिस्टम के साथ आपूर्ति की गई फ़ाइल की तुलना उपयोगिता का उपयोग करना चाहिए या उन सामग्रियों की तुलना करने के लिए फ़ाइल की तुलना टूल का उपयोग करें (देखें: विकी-फाइल की तुलना करें उपकरण ) जब आपने @Glenn नेल्सन द्वारा उल्लिखित फ़ाइल गुणों की जाँच की है।

मुझे नहीं लगता कि सीआरसी 100% सटीक है और मुझे लगता है कि फ़ाइल की लंबाई के साथ इसकी सटीकता कम हो जाती है। इसके अलावा, मेरा सुझाव है कि आप इसे स्क्रैच से लिखें क्योंकि इसके लिए बहुत सारे परीक्षण की आवश्यकता हो सकती है।

Answer 7

क्या यह जांचने के लिए हर एक बाइट को पढ़ना आवश्यक है कि क्या एक कॉपी की गई फाइल मूल के समान है? हाँ 100% निश्चित है

क्या यह जांचने के लिए हर एक बाइट को पढ़ना आवश्यक है कि क्या एक कॉपी की गई फाइल मूल के समान नहीं है? नहीं

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

यदि वह परीक्षण पास हो जाता है, तो आपको अभी भी प्रत्येक बाइट की व्यक्तिगत रूप से तुलना करने की आवश्यकता है, यदि आपको 100% निश्चित होने की आवश्यकता है, लेकिन ध्यान दें कि आधुनिक पाइपलाइन्ड सीपीयू में, और कई थ्रेड्स और संभवतः कई प्रोसेसर / सीपीयू का उपयोग करते हुए, बड़ी फ़ाइलों की ब्लॉक तुलना करना वास्तव में तेज़ है। और कुशल क्योंकि प्रक्रिया अत्यधिक समानांतर है। प्रत्येक बाइट को शामिल करने वाले किसी भी प्रकार की गणितीय संगणना से तेज़ रास्ता (हालांकि कुछ एल्गोरिदम संभवतः समानांतर भी हैं, लेकिन शायद इतनी आसानी से या इतनी अच्छी तरह से नहीं)। ऐसा इसलिए है क्योंकि सीपीयू जो पाइपलाइज्ड हैं, वे माइक्रो-कोड या हार्डवेयर (वास्तव में तेज़) और मेमोरी-टू-मेमोरी सबसिस्टम में मेमोरी की ब्लॉक-तुलना ऑपरेशन कर सकते हैं, फ़ाइलों के विशाल ब्लॉक को मेमोरी से / तक, सभी के समानांतर और साथ में करने के लिए अत्यधिक अनुकूलित हैं। हार्डवेयर। यदि आपका एप्लिकेशन इस तरह की चीज़ों को नियमित रूप से करता है, और यह एक ज्ञात प्रदर्शन अड़चन है, तो आप इसे अच्छी तरह से लिखे गए मल्टीथ्रेड कोड में लागू करने के लिए समझदार होंगे जो आपके ओएस और हार्डवेयर के समानांतर सुविधाओं का लाभ उठाता है (शायद इसके लिए डिज़ाइन की गई भाषा का उपयोग करें इस)।

यदि आप प्रत्येक फ़ाइल को एक बार संसाधित करना चाहते हैं और बाद में कई तुलनाएँ करना चाहते हैं (जहाँ आपको याद है ["कैश"] संक्षेप में, या "संपीड़ित" [जैसा कि जॉनएफ़एक्स डालता है] विश्लेषण परिणाम), तो ऐसा करने का एक महत्वपूर्ण लाभ होगा, और फिर भी, केवल अंतर (संभावना) साबित करने के लिए; समानता साबित करने के लिए, आपको अभी भी बाइट-बाय-बाइट की तुलना करने की आवश्यकता होगी।