בדקו את תשובת ה-FTP הסופית לפני שסומכים על העלאה

לקוח FTP יכול לקבל פקודת put הרבה לפני שהשרת קיבל את הקובץ, והפער בין שני האירועים האלה הוא המקום שבו מתגוררות רוב תעלומות ההעלאה. ארבעה שלבים חייבים להסתיים: הקובץ המקומי נקרא, השרת מקבל את בקשת האחסון, חיבור הנתונים נושא את הבתים, וההעברה מגיעה לתשובה סופית חיובית. השוואת השלבים שימושית יותר מהשוואת לקוחות, כי התחברות שעובדת ושם קובץ שמופיע שניהם נעצרים לפני הסיום.

תשובה מקדימה לעומת תשובה סופית

עבור STOR, תשובה 125 או 150 היא מקדימה. היא אומרת שהשרת מוכן לנסות ושחיבור נתונים נפתח, לא שהאובייקט קיים בצורתו הסופית. הפעולה מושלמת רק כשההעברה מגיעה לתשובת השלמה חיובית, בדרך כלל 226 או 250, בהקשר של אותה פעולה.

426 פירושה שההעברה בוטלה, ומספר שמודפס על ידי פקודה אחרת אינו התוצאה של העלאה זו. קראו את התשובה ששייכת ל-STOR, לא את המספר האחרון במסך. אם הלקוח יוצא לפני שהתשובה הזו מגיעה, אין לכם שום ראיה להשלמה.

חיבור בקרה לעומת חיבור נתונים

אימות ורישום תיקיות משתמשים בחיבור הבקרה. הבתים משתמשים בחיבור נתונים נפרד, ונקודת הקצה שלו מנוהלת במשא ומתן לכל העברה. התחברות מוצלחת מוכיחה את נתיב הבקרה ואינה אומרת דבר על האם כתובת הנתונים נגישה מהלקוח.

כשהשרת אינו יכול לפתוח את חיבור הנתונים, בדקו את נקודת הקצה שנקבעה במשא ומתן ואת הנתיב המותר. מצב פסיבי עדיין דורש כתובת נתונים ופורט שמישים, וחומת אש או התקן NAT בין הלקוח לשרת יכולים לאפשר את סשן הבקרה ובמקביל לחסום את טווח הנתונים. כשהשרת דוחה את בקשת האחסון, הסתכלו על שם הנתיב המרוחק, ההרשאות או מגבלות האחסון. אף אחד משני הענפים אינו מוסבר על ידי כך שחיבור הבקרה אומת.

FTP על גבי TLS לעומת SFTP

FTP על גבי TLS הוא עדיין FTP: שני חיבורים, תשובות FTP ושדרוג TLS בכל אחד. SFTP הוא תת-מערכת של SSH עם חיבור אחד ומערכת פקודות שונה לחלוטין. הם חולקים מטרה וכמעט שום דבר אחר, ולכן אבחון שעובר ביניהם מתחיל בדרך כלל בהשוואת הלוגים הלא נכונים.

אל תשביתו TLS כדי לאפשר לעוזר מתווך לבדוק את הסשן, ואל תתייחסו לכשל SFTP כאל בעיית תשובות FTP. המדריך של curl מתעד TLS מפורש, מצב פסיבי ואפשרויות העלאה אם אתם זקוקים לבדיקה בסקריפט, והוא ההפניה למה שכל דגל באמת משנה.

בחרו את הפרוטוקול שהשירות מציע בפועל לפני שאתם מאתרים בו תקלות. שרת שמדבר רק SFTP לעולם לא יפיק תשובה 226, לא משנה כיצד הלקוח מוגדר.

שם קובץ גלוי לעומת אובייקט מאוחסן

שם קובץ גלוי יכול לייצג אובייקט חלקי, במיוחד אחרי העברה שבוטלה או לקוח שיצא מוקדם. בקשו מבעל השירות להשוות את גודל קובץ הבדיקה המיועד ואת ה-hash המהימן של התוכן עם האובייקט המאוחסן כשמצפים לשימור הבתים.

מצב בינארי ומצב ASCII הם השוואה נוספת שמשנה את התוצאה. מצב ASCII יכול לתרגם סופי שורות, ולכן הבתים המאוחסנים שונים מהקובץ המקומי למרות שההעברה הצליחה. שמרו על מצב בינארי לבדיקה בית אחר בית, ואל תוסיפו אפשרויות המרה כדי לגרום להעברה כושלת להיראות אחרת.

STOR רגיל יכול להחליף קובץ קיים, והרשאה להתחבר או לרשום תיקייה אינה מבססת הרשאה ליצור או להחליף אובייקט בתוכה. השתמשו בבדיקה בשם מרוחק שלא נוצל קודם.

מה להשוות לפני ניסיון חוזר

אל תוסיפו, תמשיכו או תחזרו על העלאה בעיוורון על קובץ חלקי לא ודאי. הסכימו עם הבעלים אם להתחיל מחדש תחת שם חדש, להשתמש בהליך השחזור שהשירות תומך בו, או להסיר את אובייקט הבדיקה הכושל.

כתבו את התוצאה כאחת מארבע הצהרות: הקריאה המקומית נכשלה, האחסון נדחה, העברת הנתונים בוטלה, או ההעברה הושלמה והבתים המאוחסנים תאמו. הרשומה הזו היא תוצאה חזקה יותר משינוי מעטפת, VPN והגדרות FTP יחד עד ששם קובץ מופיע, והיא אומרת לאדם הבא איזה שלב לבדוק. שמרו את טקסט התשובה המנוקה עם אותה הצהרה. אז ניסיון חוזר הוא החלטה, לא רפלקס.