अपलोड खराब लगता है: दोनों सिरों पर हैश की तुलना करें
असफल अपलोड इस बात का प्रमाण नहीं है कि टनल ने बाइट बदले। इच्छित फ़ाइल की तुलना संग्रहीत परिणाम से करें, फिर पहली वह सीमा खोजें जहाँ वे अलग होते हैं।
जो लोग अपलोड की गई फ़ाइल नहीं खोल पाते, वे अक्सर सुनते हैं कि VPN ने उसे खराब कर दिया। यह एक परिकल्पना है, अवलोकन नहीं, और इसे जाँचा जा सकता है। टनल को छूने से पहले तय करें कि गंतव्य पर अब संग्रहीत वस्तु उस वस्तु से भिन्न है या नहीं जिसे भेजा जाना था। बाकी सब उसी उत्तर से निकलता है।
शिकायत से नहीं, इच्छित बाइट से शुरू करें
कोई हानिरहित फ़ाइल चुनें जो समस्या दोहराती हो, या असली फ़ाइल यदि नीति उसे स्रोत वातावरण छोड़ने देती है। स्थानांतरण से पहले दो बातें लिख लें: बाइट में सटीक आकार और एक आधुनिक सामग्री हैश। फ़ाइल नाम, समय-चिह्न और पूर्वावलोकन मेटाडेटा हैं, और इनमें से कोई सामग्री की पहचान नहीं करता।
हैश ऐसे एल्गोरिदम से गिनें जिसे दोनों सिरे चला सकें, और लिखें कि आपने कौन-सा इस्तेमाल किया। SHA-256 और MD5 के बीच तुलना तुलना नहीं है, और उसी नाम को संयोग से साझा करने वाली दो अलग फ़ाइलों के बीच तुलना भी तुलना नहीं है।
PS> Get-FileHash -LiteralPath "C:\uploads\report.csv" -Algorithm SHA256
Hash Path
---- ----
9F2C... C:\uploads\report.csv
Microsoft का Get-FileHash संदर्भ कमांड और उसके एल्गोरिदम पैरामीटर का दस्तावेज़ीकरण करता है, ठीक वही हिस्सा जिसे लोग छोड़ देते हैं जब तुलना कोई अर्थहीन असंगति पैदा करती है।
हर चरण पर एक हैश, वही एल्गोरिदम
अब वही एल्गोरिदम संग्रहीत वस्तु पर वहाँ गिनें जहाँ वह अंततः रहती है, किसी अधिकृत विधि से, किसी अन्य उपकरण से गुज़री प्रति पर नहीं। प्राप्त फ़ाइल को स्थानीय रूप से सहेजना और उस प्रति का हैश लेना एक ऐसा चरण जोड़ता है जिसे आपने जाँचा नहीं है।
यदि सेवा अपना स्वयं का अखंडता मान दिखाती है, तो उसे अलग अवलोकन मानें। प्रदाता द्वारा बताया गया चेकसम आपको बता सकता है कि प्रदाता क्या संग्रहीत मानता है, और यह उसी दावे जैसा नहीं है जो आपके क्लाइंट ने भेजा।
तीन परिणाम संभव हैं, और वे अलग-अलग दिशाओं में इशारा करते हैं। समान हैश का अर्थ है कि बाइट अपरिवर्तित पहुँचे। ज्ञात रूपांतरण के साथ भिन्न हैश का अर्थ है कि सेवा ने जानबूझकर नई वस्तु बनाई। रूपांतरण के बिना भिन्न हैश का अर्थ है कि दो बिंदुओं के बीच किसी चीज़ ने सामग्री बदली, और अगला कदम यह खोजना है कि ऐसा सबसे पहली किस सीमा पर हुआ।
स्थानांतरण विफलता को रूपांतरण से अलग करें
आंशिक अपलोड और खराब अपलोड फ़ाइल ब्राउज़र में एक जैसे दिखते हैं और अलग-अलग खराबियाँ हैं। जाँचें कि स्थानांतरण पूरा हुआ या नहीं: रद्द किया गया अनुरोध दिखाने वाला एप्लिकेशन लॉग, ऐसी संग्रहीत फ़ाइल जिसका आकार स्रोत का उपसर्ग है, या ऐसी वस्तु जो वास्तव में अपेक्षित एक्सटेंशन के अंतर्गत सहेजा गया त्रुटि पृष्ठ है, सभी बदली हुई बाइट के बजाय अपूर्ण स्थानांतरण की ओर संकेत करते हैं।
रूपांतरण दूसरा सामान्य स्पष्टीकरण है। छवियों को फिर से संपीड़ित करने, CSV पंक्ति-अंत फिर से लिखने या दस्तावेज़ बदलने वाली सेवा वैध रूप से स्रोत से भिन्न हैश बनाएगी, और वह भ्रष्टाचार नहीं है। उस चरण की तुलना करें जो स्वयं को वफ़ादार प्रति बताता है, अंतिम प्रस्तुति प्रारूप की नहीं।
विलंब और हानि तीसरी श्रेणी में आते हैं। वे क्लाइंट का समय समाप्त करा सकते हैं, पुनः प्रयास करा सकते हैं या छोड़ने पर मजबूर कर सकते हैं, और इनमें से कुछ भी यह नहीं दर्शाता कि सर्वर द्वारा स्वीकार किए गए बाइट चुपचाप बदले गए। टनल को कुछ भी मानने से पहले स्थानांतरण का परिणाम देखें।
सब कुछ बदले बिना दूसरा रास्ता आज़माएँ
यदि हैश वास्तव में भिन्न हैं और कोई रूपांतरण नहीं है, तो वही फ़ाइल, क्लाइंट, प्रोटोकॉल और गंतव्य किसी अन्य समर्थित रास्ते से दोहराएँ, जैसे VPN के बजाय स्थानीय नेटवर्क। एक चर बदलें। क्लाइंट, समापन बिंदु और उपकरण एक साथ बदलने से आपको ऐसा परिणाम मिलता है जिसे आप निर्धारित नहीं कर सकते।
तुलना को दोनों दिशाओं में ईमानदार रखें। हैश आपको बताता है कि दो बिंदु सामग्री पर असहमत या सहमत हैं; यह नहीं बताता कि कौन-सा पक्ष भरोसेमंद है, इसलिए अपेक्षित मान और सत्यापन को उसी भरोसा मॉडल के भीतर रखें जिस पर आप वास्तव में निर्भर हैं।
टिकट में एक विशिष्ट वाक्य के साथ समाप्त करें: स्थानांतरण जल्दी रुक गया, एप्लिकेशन ने वस्तु का रूपांतरण किया, भंडारण ने उसे बदला, या बाइट मेल खाते हैं और उन्हें पढ़ना ही विफलता है। इनमें से हर एक का अलग स्वामी है, और इनमें से कोई भी डिफ़ॉल्ट रूप से VPN नहीं है।