अपलोडमा भरोसा गर्नु अघि अन्तिम 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 सेटिङ सँगै बदल्नुभन्दा बलियो नतिजा हो, र अर्को व्यक्तिलाई कुन चरण जाँच्ने भनेर बताउँछ। त्यो कथनसँगै सफा गरिएको जवाफ पाठ राख्नुहोस्। तब पुनः प्रयास एउटा निर्णय हो, प्रतिक्रिया होइन।