الخلاصة

  • يمنع STOU المرسل من فرض اسم الملف الجديد، فيخصص الخادم مساراً فريداً داخل الدليل الحالي. لكنه لا يحدد من يطالب بالعنصر أو كم يبقى أو متى يجوز حذفه.
  • يفصل 125 FILE: أو 150 FILE: بين دليل تخصيص الاسم ودليل اكتمال النقل اللاحق؛ لذلك قد يظهر في الجرد اسم حقيقي لمحاولة لم تنتج ملفاً كاملاً.
  • تاريخ مجلدات التجميع يبين أن التسمية، والإذن، والإخطار، والاستلام، والتحقق مما إذا كانت المسارات المتعددة تعود إلى الملف المخزن نفسه، والحفظ قرارات متعاقبة. جمعها في حالة واحدة يجعل التنظيف السريع خطراً على محتوى مشروع.

أربعة صفوف لا تعني الشيء نفسه

الصف الأول في الجرد يحمل مساراً أعاده الخادم، لكن سجل التحكم لا يحمل جواب إتمام. ربما فشل اتصال البيانات بعد تخصيص الاسم. الصف الثاني يحمل 226 أو 250، إلا أن نظام الاستلام لم يربط الملف بمستلمه. في الصف الثالث اكتمل الربط، لكن الإخطار فشل أو لم يُقرأ. وفي الصف الرابع مضى العمر المحدد، ويقترح نظام التنظيف حذف العنصر.

إذا اختُزلت الفئات الأربع إلى «ملفات قديمة»، يصبح الحذف قراراً مبنياً على العمر وحده. لكنه عمر لأحداث مختلفة: منذ تخصيص اسم، أو منذ إتمام نقل، أو منذ آخر محاولة إخطار، أو منذ آخر مطالبة مؤكدة. وقد لا يكون العنصر الأول ملفاً كاملاً أصلاً، بينما قد يكون الثالث ملفاً صحيحاً ينتظر شخصاً لم تصله الرسالة.

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

فكرة التجميع فصلت التسليم عن مساحة المستلم

بحث RFC 505 في 1973 مشكلة إرسال ملف إلى شخص على مضيف بعيد من دون معرفة كلمة مروره. كان أحد الحلول أن يوضع الملف في مجلد تجميع بدلاً من إدخاله مباشرة إلى دليل المستلم المزعوم. يتلقى المستلم إشعاراً، ثم يستطيع نسخ العنصر لاحقاً إلى مساحته.

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

كان POOL id name المقترح يقبل اسماً مرغوباً، ويضيف الخادم بادئة أو لاحقة عند الحاجة إلى إبقائه فريداً في مجلد التجميع. لذلك لم يكن اسم المرسل بالضرورة هو المسار المحلي النهائي. وهذه المغايرة ليست خطأ؛ إنها نتيجة كون الخادم أدرى بالأسماء الموجودة في المساحة التي يديرها.

غير أن RFC 505 ظل اقتراحاً. لا يثبت النص أن POOL أصبح خدمة منتشرة ثم تحول مباشرة إلى STOU. كما أقر بأن البروتوكولات العليا كانت تعرف أكثر مما ينبغي عن اختلاف أنظمة التشغيل. ما انتقل إلى النقاش اللاحق هو معضلة المسؤولية: كيف يستقبل الخادم شيئاً من دون منح المرسل حق الكتابة المباشرة في مساحة المستلم، وكيف يعيد مرجعاً يمكن استخدامه في بقية دورة الحيازة.

STOU سمّى العنصر ولم يعيّن من يستلمه

قدم RFC 949 في يوليو 1985 أمر STOU، واستعمل مجلدات تجميع لطوابير الطابعات والفاكس وآلات تثقيب البطاقات أمثلةً. في هذه البيئات قد يكون المطلوب إدخال مهمة إلى الطابور، لا اختيار اسم بعينه في نظام الخادم.

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

ألزم الاقتراح الخادم بإبلاغ المرسل بالاسم المولد. من دون المرجع لا يستطيع المرسل أو نظام الإخطار ربط المهمة بموضعها. إلا أن RFC 949 رفض أن يصبح الأمر طريقاً لتجاوز التحكم في الوصول أو المصادقة أو المحاسبة. قد يكون للمستخدم إذن بإيداع عنصر في مجلد تجميع، من دون أن يكون له حق اختيار موضع مستلم بعينه أو إدارة العناصر الأخرى.

هنا يتضح ما لم يحدده الأمر. لا يخبر STOU من هو المستلم الفعلي، ولا يثبت أنه علم بالعنصر، ولا يضع مدة احتفاظ، ولا يمنح عامل التنظيف سلطة الحذف. تلك سياسات حول الحيازة، لا حول تخصيص الاسم.

الاسم يظهر في الجرد قبل اكتمال الحالة

أدرج RFC 959 في أكتوبر 1985 STOU ضمن سبعة أوامر FTP اختيارية جديدة. صيغته STOU <CRLF>، بلا وسيطة لمسار الملف. يخصص الخادم اسماً فريداً بالنسبة إلى الدليل الحالي. لذلك قد يكون سياق الدليل قد تحدد في الجلسة، لكن الاسم الجديد نفسه لا يأتي من المرسل.

وقع النص في تناقض بشأن الرد. قال إن الاسم يظهر في «250 Transfer Started»، مع أن تعريفاته تجعل 125 علامة أن اتصال البيانات مفتوح والنقل يبدأ، و150 علامة أن حالة الملف سليمة والاتصال على وشك أن يفتح، و250 علامة اكتمال الإجراء. كما يضع جدول STOU جواباً تمهيدياً 125 أو 150 قبل 226 أو 250.

صحح RFC 1123 ذلك في 1989. يجب أن يظهر المسار الفعلي قبل النقل بالصيغة 125 FILE: pppp أو 150 FILE: pppp. تفيد FILE: محلل البرامج، ويفيد الرمز التمهيدي أمين الجرد: المسار خُصص للشيء المزمع كتابته، لكن النتيجة النهائية لم تصل بعد.

بعدها قد يأتي 226 أو 250، وقد تأتي أخطاء مثل 425 و426 و451 و551 و552. لذلك من المشروع أن يحتوي سجل التخصيص اسماً لا يقابله نقل ناجح. ولا يثبت جواب الإتمام، حين يصل، أن الملف سيبقى إلى أن يطالب به المستلم، أو أنه نُسخ احتياطياً، أو أنه لن يُعاد تسميته.

يطلب RFC 1123 كذلك من User-FTP قبول المسارات البعيدة كسلاسل محارف اعتباطية وعدم إخضاعها لأعراف نظام التشغيل المحلي. إذا غيّر نظام الجرد الاسم الذي أعاده الخادم، فقد يفشل الإخطار أو الالتقاط لأن المرجع المخزن لم يعد هو المرجع البعيد.

المسار الأول كان دائماً تابعاً لنظام الحماية

يعود أصل هذه الحدود إلى RFC 172 في 1971. عرّف الملف من خلال pathname داخل النظام، ولم يوحد أعراف التسمية بين المضيفين. كان على المستخدم فهم نظام الملفات البعيد، وظل الوصول الانتقائي في يد النظام المقيم. نقل FTP معرفات وكلمات مرور ومسارات، لكنه لم يستبدل قواعد الحماية.

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

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

الاستئناف قد يزيد العناصر اليتيمة

شرح RFC 3659 استئناف النقل في نمط الدفق باستخدام REST، وقال إن أمر النقل التالي يكون عادة RETR أو STOR. قد يسمح خادم بـ APPE أو STOU بعده، لكن ذلك غير موصى به، ومعنى STOU في هذا السياق غير محدد. تخزين بقية ملف تحت اسم فريد جديد نادراً ما يحقق استئناف الملف السابق الذي نُقل جزء منه.

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

ويعرّف RFC 3659 حقيقة Unique= في القوائم. إذا تساوى token لمسارين فهما يشيران إلى الملف المخزن نفسه. لكنه token معتم، حساس لحالة الأحرف، ولا يلزم أن تبقى علاقة التعيين ثابتة إلا خلال عمر اتصال التحكم على الأقل. هذا مختلف عن STOU: فرادة اسم جديد في دليل لا تجيب عما إذا كانت المسارات المتعددة تعود إلى الملف المخزن نفسه.

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

الإدراج في السجل لا ينظف المجلد

يعرض RFC 5797 STOU في سجل أوامر FTP وامتداداته كأمر أساسي اختياري يحيل إلى RFC 959 وRFC 1123. الهدف الأساسي للسجل منع تعارض أسماء الأوامر والامتدادات، لا قياس انتشارها أو نجاحها أو تنفيذها اليوم.

ويوثق سجل IANA لأوامر FTP وامتداداته التخصيص الحالي. لا يقول الصف كم خادماً يدعم الأمر، ولا كيف يدير أي خادم العناصر غير المستلمة. ورمز FEAT المسمى base عنصر ثابت للأوامر الأساسية، لا سطراً يُفترض أن يظهر في رد FEAT. لا يستطيع أمين المجلد الاستناد إلى التسجيل ليقرر أن كل تخصيص اتبع السلوك نفسه.

الملف اليتيم ليس آمناً لمجرد أن اسمه لم يتصادم

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

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