اپ لوڈ پر بھروسہ کرنے سے پہلے آخری 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 ترتیبات ایک ساتھ بدلنے سے زیادہ مضبوط نتیجہ ہے، اور اگلے شخص کو بتاتا ہے کہ کون سا مرحلہ دیکھنا ہے۔ اس بیان کے ساتھ صاف شدہ جواب متن رکھیں۔ تب دوبارہ کوشش ایک فیصلہ ہے، ردعمل نہیں۔