الخلاصة

  • قسّم FTP إعادة التسمية إلى RNFR وRNTO؛ وكان 350 بعد الأمر الأول قبولاً إيجابياً وسيطاً، لا دليلاً على تغير الاسم.
  • فصلت RFC 3659 لاحقاً بين قدرة المستخدم على اختيار كائن المصدر، وقدرته على إنشاء اسم في دليل الوجهة، ودليل Unique الاختياري على استمرارية الكائن.
  • تضبط المعايير ترتيب الأوامر ومعنى الردود، ولا تعد بالذرية أو الديمومة أو سياسة الاستبدال أو السلامة من الأعطال أو وجود التنفيذ على خادم حالي.

جواب إيجابي لعملية غير مكتملة

يرسل العميل RNFR old-name، فيجيب الخادم 350 Requested file action pending further information. تبدأ الشفرة برقم إيجابي، ولذلك قد تسجلها لوحة مبسطة نجاحاً.

لكن الاسم لم يتغير بعد. تعرّف RFC 959 فئة 3xx بأنها رد إيجابي وسيط: قُبل الأمر، غير أن الفعل المطلوب بقي معلقاً في انتظار معلومات إضافية. والمعلومة الناقصة هنا هي مسار الوجهة الذي يحمله RNTO.

احتوت RFC 765 البنية نفسها من قبل. يحدد RNFR الملف المراد تغيير اسمه، ويجب أن يتلوه RNTO مباشرة؛ ثم يعطي الأمر الثاني المسار الجديد للملف المحدد في الأمر السابق. الأمران معاً، لا الأول وحده، يسببان إعادة التسمية.

لم يخف FTP هذه الوقفة داخل كلمة عامة مثل «نجاح». جعل لها فئة جواب تقول للعميل: يمكنك المتابعة، لكن لا تدّع أن التحويل قد اكتمل.

سياق محفوظ داخل جلسة التحكم

ينتمي RNFR وRNTO إلى مجموعة أوامر متسلسلة. إذا فشلت خطوة، توجّه المواصفات إلى إعادة السلسلة من بدايتها. يحتفظ الخادم إذن بسياق يكفي لتفسير أمر الوجهة التالي في اتصال التحكم ذاته.

لا يعني ذلك أنه أصدر معرّف معاملة دائم، أو قفل المصدر، أو حجز الاسم الجديد. كلمة «مباشرة» تقيد الاقتران: يشير RNTO إلى ملف RNFR السابق مباشرة. ومن دون الترتيب الصحيح قد يرد الخادم بـ503 Bad sequence of commands.

لهذا لا تكفي سطور سجل منفصلة تحمل اسمين. يجب حفظ هوية الجلسة والترتيب الدقيق. وإلا تعذر إثبات أي مصدر اقترن بأي وجهة وفق آلة حالات البروتوكول.

توجد ثلاث وقائع مختلفة: اقترح العميل مصدراً، وقبل الخادم خطوة مصدر معلقة، ثم أكمل الخادم تغيير الوجهة أو رفضه. اختزالها في خانة نجاح واحدة يصنع في السجل إعادة تسمية لم تحدث.

لماذا لا يتساوى 350 و250

تعني فئة 2xx في RFC 959 اكتمالاً إيجابياً: انتهى الفعل المطلوب بنجاح ويمكن بدء طلب جديد. ويعني 250 تحديداً أن فعل الملف المطلوب سليم وقد اكتمل. أما 350 فيصرح بأن الفعل ينتظر مزيداً من المعلومات.

كلاهما غير فاشل، لكنهما لا ينقلان المسؤولية نفسها. يجيز 350 متابعة التسلسل؛ ويمنح 250 دليل الاكتمال على مستوى تبادل FTP. الرقم الأول ليس درجة رضا، بل وصف لمرحلة.

إذا ضاع الرد النهائي، تصبح النتيجة مجهولة للعميل، لا فاشلة بالضرورة. ينبغي عندئذ فحص فضاء الأسماء قبل التكرار. ليس 350 القديم تذكرة معاملة دائمة يمكن استئنافها بعد الانقطاع؛ وقاعدة التعافي في التسلسل تعيد بناء السياق من المصدر.

سلطة المصدر ليست سلطة الوجهة

جعلت RFC 3659 الفرق بين الجانبين أوضح عبر حقيقة perm. يشير الحرف f على كائن إلى أن مستخدم FTP الحالي يستطيع جعله موضوع RNFR. ويشير c على دليل إلى إمكانية إنشاء ملفات فيه، وأن RNTO لأسماء داخله مرجح النجاح.

الأولى قدرة مرتبطة بكائن المصدر، والثانية مرتبطة بحاوية الوجهة. لا تتحولان إلى إذن عام اسمه «تحرير». قد يملك شخص سلطة تحرير اسم قائم، من دون أن يملك إنشاء اسم في كل مساحة أخرى.

والصياغة «مرجح النجاح» مقصودة. تصف حقيقة القائمة قدرة متوقعة وقت الرصد؛ فلا تحجز الاسم ولا تجمد السياسة ولا تلغي المنافسة. يبقى الرد النهائي هو الحكم على الطلب الفعلي.

أثر للكائن تحت اسمين

عرّفت RFC 3659 أيضاً حقيقة Unique الاختيارية. إذا وفرها الخادم، يفترض أن تحصل المسارات التي تشير إلى الملف الأساسي نفسه على القيمة المعتمة ذاتها، وأن تختلف القيم لملفات مختلفة. ويجب أن يبقى هذا الربط متسقاً طوال اتصال التحكم على الأقل.

يعرض مثال المواصفة mlst.c بقيمة Unique معينة. يتلقى العميل 350 بعد RNFR mlst.c، ثم 250 بعد RNTO list.c. وعند الفحص يظهر list.c بالقيمة ذاتها. تغير الاسم، بينما بقي أثر الكائن المحدود الذي أصدره الخادم.

هذه القيمة ليست معرفاً عالمياً ولا بصمة محتوى ولا هوية أبدية. كما لا يلزم الخادم بدعم حقائق MLSx بعينها. يبيّن المثال فقط إمكان جمع دليلين مختلفين: الرد النهائي يثبت فعل البروتوكول، والقيمة الاختيارية تقوي الاستدلال بأن الاسمين أحالا إلى الكائن الأساسي نفسه ضمن نطاقها.

سجل الأوامر لا يَعِد بسلوك نظام الملفات

أبقت RFC 1123 RNFR وRNTO ضمن متطلبات أوامر مضيف FTP. ثم أدرجتهما RFC 5797 ضمن أوامر الأساس الإلزامية، ويحافظ سجل IANA لأوامر FTP وامتداداته على المدخلين.

يثبت ذلك تنسيق مفردات قابلة للتشغيل البيني، لا عقداً لمخزن الملفات. لا تجيب هذه السجلات هل التغيير ذري أمام القراء المتزامنين، أو هل تستبدل وجهة موجودة، أو متى تصبح البيانات دائمة، أو ماذا يحدث بعد عطل، أو كيف تعالج حدود أنظمة الملفات. ولا تثبت أن خادماً بعينه يسمح بالأمرين اليوم.

الحقيقة الأضيق كافية: ألزم FTP الطرفين بالتمييز بين مصدر مقبول ينتظر المتابعة وإعادة تسمية مكتملة. أما الطبقات الأدنى فتحتاج إلى دليل مستقل من التنفيذ والسياسة.

ملف بين اسمين

تبدأ عمليات تحكم حديثة كثيرة بقول الخادم إن المقترح صالح بما يكفي للمتابعة. التصميم الجيد يسمي هذه الحالة، ويحدد الجلسة أو المعاملة التي تملكها، وما يبطلها، وأي نتيجة تثبت الالتزام النهائي.

ويفصل أيضاً بين الإذن على المصدر، والإذن على حاوية الوجهة، وهوية الكائن تحت الاسم. دمجها في علامة نجاح واحدة يفسد التدقيق ويوسع التفويض.

لم يكن 350 نجاحاً ضعيفاً، بل نجاحاً دقيقاً غير نهائي. دخل الملف تسلسل أوامر، ولم يدخل بعد مساراً جديداً. إعادة التسمية لم تحدث بعد، وكان الرد يقول ذلك صراحة.

المصادر