अपलोडवर विश्वास ठेवण्यापूर्वी अंतिम FTP प्रतिसाद तपासा

FTP क्लायंट सर्व्हरने फाइल मिळवण्याच्या खूप आधी put कमांड स्वीकारू शकतो, आणि या दोन घटनांमधील अंतरातच बहुतेक अपलोड कोडी दडलेली असतात. चार टप्पे पूर्ण व्हायला हवेत: स्थानिक फाइल वाचली जाते, सर्व्हर साठवण विनंती स्वीकारतो, डेटा कनेक्शन बाइट्स वाहून नेते, आणि हस्तांतरण अंतिम सकारात्मक प्रतिसादापर्यंत पोहोचते. क्लायंटची तुलना करण्यापेक्षा हे टप्पे तुलना करणे अधिक उपयुक्त आहे, कारण यशस्वी लॉगिन आणि दिसणारे फाइलनाव दोन्ही पूर्ततेच्या आधी थांबतात.

प्राथमिक प्रतिसाद व अंतिम प्रतिसाद

STOR साठी, 125 किंवा 150 प्रतिसाद प्राथमिक असतो. सर्व्हर प्रयत्न करायला तयार आहे आणि डेटा कनेक्शन उघडत आहे एवढेच तो सांगतो; ऑब्जेक्ट त्याच्या अंतिम स्वरूपात आहे असे नाही. त्या ऑपरेशनच्या संदर्भात हस्तांतरण सकारात्मक पूर्तता प्रतिसादापर्यंत, सामान्यतः 226 किंवा 250 पर्यंत पोहोचल्यावरच ऑपरेशन पूर्ण होते.

426 म्हणजे हस्तांतरण थांबवले गेले, आणि दुसऱ्या कमांडने छापलेला आकडा या अपलोडचा निकाल नाही. स्क्रीनवरील शेवटचा आकडा नव्हे, त्या STOR चा प्रतिसाद वाचा. तो प्रतिसाद येण्यापूर्वी क्लायंट बाहेर पडला, तर पूर्ततेचा कोणताही पुरावा तुमच्याकडे नाही.

नियंत्रण कनेक्शन व डेटा कनेक्शन

प्रमाणीकरण आणि डिरेक्टरी सूची नियंत्रण कनेक्शन वापरतात. बाइट्स स्वतंत्र डेटा कनेक्शन वापरतात, आणि त्याचा एंडपॉइंट प्रत्येक हस्तांतरणासाठी ठरवला जातो. यशस्वी लॉगिन नियंत्रण मार्ग सिद्ध करते, पण डेटा पत्ता क्लायंटपासून पोहोचण्यायोग्य आहे का याबद्दल काहीही सांगत नाही.

सर्व्हर डेटा कनेक्शन उघडू शकत नाही तेव्हा ठरवलेला एंडपॉइंट आणि परवानगी दिलेला मार्ग तपासा. पॅसिव्ह मोडलाही वापरण्यायोग्य डेटा पत्ता आणि पोर्ट लागतो, आणि क्लायंट व सर्व्हरमधील फायरवॉल किंवा NAT उपकरण नियंत्रण सत्राला परवानगी देताना डेटा श्रेणी अडवू शकते. उलट सर्व्हर साठवण विनंती नाकारत असेल, तर रिमोट पथनाव, परवानग्या किंवा साठवण मर्यादा पाहा. नियंत्रण कनेक्शनने प्रमाणीकरण केले यावरून या दोन्ही शाखांचे स्पष्टीकरण होत नाही.

TLS वरील FTP व SFTP

TLS वरील FTP अजूनही FTP आहे: दोन कनेक्शन, FTP प्रतिसाद, आणि प्रत्येकावर TLS अपग्रेड. SFTP ही SSH उपप्रणाली आहे, एकच कनेक्शन आणि पूर्णपणे वेगळा कमांड संच. ते फक्त उद्देश सामायिक करतात, बाकी जवळपास काहीही नाही, म्हणून दोन्हींमध्ये मिसळणारे निदान सहसा चुकीचे लॉग तुलना करून सुरू होते.

सत्र तपासण्यासाठी मधल्या सहाय्यकाला परवानगी देण्यासाठी TLS बंद करू नका, आणि SFTP अपयशाला FTP प्रतिसादाची समस्या मानू नका. स्क्रिप्टेड चाचणी हवी असल्यास, curl मॅन्युअल स्पष्ट TLS, पॅसिव्ह मोड आणि अपलोड पर्यायांचे दस्तऐवज करते, आणि प्रत्येक फ्लॅग प्रत्यक्षात काय बदलतो याचा तो संदर्भ आहे.

डीबग करण्यापूर्वी सेवा प्रत्यक्षात देते तो प्रोटोकॉल निवडा. फक्त SFTP बोलणारा सर्व्हर, क्लायंट कसाही कॉन्फिगर केला तरी 226 प्रतिसाद कधीही देणार नाही.

दिसणारे फाइलनाव व साठवलेला ऑब्जेक्ट

दिसणारे फाइलनाव अपूर्ण ऑब्जेक्ट दर्शवू शकते, विशेषतः हस्तांतरण थांबवल्यानंतर किंवा क्लायंट लवकर बाहेर पडल्यानंतर. बाइट जतन अपेक्षित असेल, तर सेवेच्या मालकाला हेतू असलेल्या चाचणी फाइलचा आकार आणि विश्वासार्ह सामग्री हॅश साठवलेल्या ऑब्जेक्टशी तुलना करायला सांगा.

बायनरी आणि ASCII मोड हे निकाल बदलणारे आणखी एक तुलनासाधन आहे. ASCII मोड ओळींचे टोक बदलू शकतो, त्यामुळे हस्तांतरण यशस्वी झाले तरी साठवलेले बाइट स्थानिक फाइलपेक्षा वेगळे असतात. बाइट-दर-बाइट तपासणीसाठी बायनरी मोड ठेवा, आणि अपयशी हस्तांतरण वेगळे दिसावे म्हणून रूपांतरण पर्याय जोडू नका.

साधारण STOR विद्यमान फाइल बदलू शकतो, आणि लॉगिन किंवा डिरेक्टरी सूचीची परवानगी त्या डिरेक्टरीत ऑब्जेक्ट तयार करण्याची किंवा बदलण्याची परवानगी ठरवत नाही. चाचणीसाठी यापूर्वी न वापरलेले रिमोट नाव वापरा.

पुन्हा प्रयत्न करण्यापूर्वी काय तुलना करावे

अनिश्चित अपूर्ण फाइलवर डोळे झाकून जोडू नका, पुन्हा सुरू करू नका किंवा पुन्हा पाठवू नका. नवीन नावाने पुन्हा सुरुवात करायची, सेवेची समर्थित पुनर्प्राप्ती प्रक्रिया वापरायची, की अपयशी चाचणी ऑब्जेक्ट काढायचा, हे मालकाशी ठरवा.

निकाल चारपैकी एका विधानात लिहा: स्थानिक वाचन अपयशी झाले, साठवण नाकारली गेली, डेटा हस्तांतरण थांबले, किंवा हस्तांतरण पूर्ण झाले आणि साठवलेले बाइट जुळले. फाइलनाव दिसेपर्यंत शेल, VPN आणि FTP सेटिंग्ज एकत्र बदलण्यापेक्षा हा नोंद अधिक मजबूत निकाल आहे, आणि पुढच्या व्यक्तीला कोणता टप्पा तपासायचा हे सांगते. त्या विधानासोबत स्वच्छ केलेला प्रतिसाद मजकूर ठेवा. मग पुन्हा प्रयत्न करणे ही प्रतिक्रिया नव्हे, निर्णय असतो.