ההעלאה נראית פגומה: השוו גיבובים בשני הקצוות

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

התחילו בבייטים המיועדים, לא בתלונה

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

חשבו את הגיבוב באלגוריתם ששני הקצוות יכולים להריץ, ורשמו באיזה השתמשתם. השוואה בין SHA-256 ל-MD5 אינה השוואה, וגם לא השוואה בין שני קבצים שונים שמקרה שיתפו שם.

PS> Get-FileHash -LiteralPath "C:\uploads\report.csv" -Algorithm SHA256
Hash                                                        Path
----                                                        ----
9F2C...                                                      C:\uploads\report.csv

המסמך של Microsoft על Get-FileHash מתעד את הפקודה ואת פרמטר האלגוריתם שלה, בדיוק את החלק שאנשים מדלגים עליו כשהשוואה מפיקה אי-התאמה חסרת משמעות.

גיבוב אחד לכל שלב, אותו אלגוריתם

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

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

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

הפרידו כשל העברה משינוי

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

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

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

נסו נתיב שני בלי לשנות הכול

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

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

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