د 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 تنظیمات یوځای بدل کړئ ترڅو فایل‌نوم ښکاره شي، او بل کس ته وایي چې کوم پړاو وګوري. له هغې جملې سره پاک شوی ځواب متن وساتئ. بیا هڅه یوه پرېکړه ده، نه غبرګون.