ידע בסיסי על בקרת הרשאות בלעדיות בהעברת קבצים — נעילת קבצים ושיטות עבודה מומלצות ל-claim אטומי

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

במאמר הזה נבחן את בקרת ההרשאות הבלעדיות בהעברת קבצים סביב נעילת קבצים, claim אטומי,‏ temp -> rename ואידמפוטנטיות.

נסדר מונחים קודם

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

מפת הידע של המאמר

המאמר הזה מסדר גישה שבה מתכננים העברת קבצים דרך תיקיות משותפות או תהליכי אצווה לילי לא בהסתמכות על נעילת מערכת ההפעלה, אלא כפרוטוקול מסירה. תופסים את זכות העיבוד ב-claim אטומי לפני הקריאה, כולאים את הקובץ שנוצר תחת שם temp, ואחרי close מפרסמים אותו ב-rename לשם final, ומציינים סיום לא בניחוש לפי גודל או חותמת זמן אלא במפורש עם done/manifest. אם משתמשים ב-lock file, הופכים אותו לצורת lease עם ownerId ו-expiresAt כדי להיערך ל-stale lock, ותוך התחשבות בכך ש-byte-range lock של Windows מתעלם ממנו כשמדובר בקובץ ממופה לזיכרון, ושadvisory lock לא יעיל מול צד שלא שומר על ההסכם, המסקנה היא שבפועל בשטח חזק יותר תכנון שבו בסוף אידמפוטנטיות קולטת גם עיבוד חוזר של אותו קלט.

flowchart LR
    accTitle: מפת הידע של בקרת ההרשאות הבלעדיות בהעברת קבצים
    accDescr: תרשים המראה איך פרוטוקול המסירה משלב claim אטומי, פרסום בסדר temp->rename, done/manifest, קובץ lock מסוג lease, ואידמפוטנטיות, ולאיזה אנטי-דפוס כל אחד מהם מתאים כמענה למניעת תקריות כמו עיבוד כפול או קריאת קובץ שכתיבתו לא הושלמה.
    file_handoff_protocol["פרוטוקול מסירת הקבצים"]
    atomic_claim["תפיסה אטומית (claim)"]
    temp_then_rename_publish["פרסום בסדר temp ‏-> close ‏-> rename/replace"]
    done_manifest_file["קובץ done/manifest"]
    lock_file_lease["קובץ נעילה מבוסס lease"]
    idempotent_processing["עיבוד שמניח אידמפוטנטיות"]
    os_file_lock["נעילת קובץ של מערכת ההפעלה"]
    atomic_creation["יצירה אטומית (CreateNew / O_CREAT|O_EXCL)"]
    duplicate_processing["עיבוד כפול (חיוב כפול, שליחה כפולה, אובדן עדכון)"]
    exists_then_create_antipattern["בדיקה דו-שלבית של Exists ואחריה Create"]
    direct_final_write_antipattern["כתיבה ישירה אל שם הקובץ הסופי"]
    partial_write_read["תקלה של קריאת קובץ שכתיבתו טרם הושלמה"]
    size_stability_completion_check["קביעת סיום לפי התייצבות גודל הקובץ"]
    shared_file_mutual_update_antipattern["אנטי-דפוס של עדכון הדדי של קובץ משותף"]
    stale_lock["stale lock"]
    byte_range_lock["byte-range lock (נעילת טווח)"]
    heterogeneous_system_integration["שילוב בין מערכות שונות"]
    advisory_lock["advisory lock"]
    cross_volume_rename_fallback["נפילה חזרה ל-rename חוצה כוננים (העתקה + מחיקה)"]
    smb_share_file_handoff["העברת קבצים דרך תיקייה משותפת (SMB)"]
    rename_fails_on_open_handle["‏rename שנכשל רק משום שהקובץ פתוח"]
    file_timestamp_unreliability["חוסר האמינות של חותמות הזמן של קבצים"]
    periodic_directory_listing["סריקת ספרייה מחזורית"]
    change_notification_loss["אובדן התראות שינוי"]
    file_handoff_protocol -->|"משתמש ב"| atomic_claim
    file_handoff_protocol -->|"משתמש ב"| temp_then_rename_publish
    file_handoff_protocol -->|"משתמש ב"| done_manifest_file
    file_handoff_protocol -->|"משתמש ב"| lock_file_lease
    file_handoff_protocol -->|"משתמש ב"| idempotent_processing
    file_handoff_protocol -.->|"משתמש ב"| os_file_lock
    atomic_claim -.->|"משתמש ב"| atomic_creation
    atomic_claim -->|"מונע"| duplicate_processing
    exists_then_create_antipattern -->|"עלול לגרום ל"| duplicate_processing
    atomic_claim -->|"מענה מומלץ ל"| exists_then_create_antipattern
    atomic_creation -->|"מענה מומלץ ל"| exists_then_create_antipattern
    direct_final_write_antipattern -->|"עלול לגרום ל"| partial_write_read
    temp_then_rename_publish -->|"מונע"| partial_write_read
    size_stability_completion_check -.->|"עלול לגרום ל"| partial_write_read
    done_manifest_file -->|"מענה מומלץ ל"| size_stability_completion_check
    shared_file_mutual_update_antipattern -->|"עלול לגרום ל"| duplicate_processing
    idempotent_processing -->|"מענה מומלץ ל"| duplicate_processing
    lock_file_lease -->|"מענה מומלץ ל"| stale_lock
    lock_file_lease -->|"מחייב"| atomic_creation
    os_file_lock -->|"משתמש ב"| byte_range_lock
    os_file_lock -.->|"מצמצם"| duplicate_processing
    os_file_lock -->|"שימוש לא מומלץ ל"| heterogeneous_system_integration
    advisory_lock -.->|"שימוש לא מומלץ ל"| heterogeneous_system_integration
    temp_then_rename_publish -.->|"אינו מתיישב עם"| cross_volume_rename_fallback
    smb_share_file_handoff -.->|"עלול לגרום ל"| cross_volume_rename_fallback
    smb_share_file_handoff -.->|"עלול לגרום ל"| rename_fails_on_open_handle
    done_manifest_file -->|"מענה מומלץ ל"| file_timestamp_unreliability
    periodic_directory_listing -->|"מענה מומלץ ל"| change_notification_loss
    smb_share_file_handoff -.->|"עלול לגרום ל"| change_notification_loss

בתרשים, קו מלא מציין קשר שמתקיים תמיד וקו מקווקו מציין קשר מותנה (תנאי ההתקיימות מפורטים בהסבר של כל קשר בעמוד המפורט). רשימת כל הקשרים (סך הכול 29, עם אסמכתה ורמת ודאות) והגדרות המושגים המרכזיים מרוכזות בעמוד המפורט של מפת הידע (ביפנית). נתונים: JSON-LD / Turtle

תוכן עניינים

1. קודם המסקנה (במשפט אחד)
2. תבניות התנגשות שקורות בהעברת קבצים (תרשים)
   • 2.1. קוראים קובץ שכתיבתו טרם הושלמה
   • 2.2. כמה עובדים תופסים את אותו קובץ בו-זמנית
   • 2.3. כולם נעצרים בגלל stale lock
3. אנטי-דפוסים
   • 3.1. בדיקה דו-שלבית של Exists -> Create
   • 3.2. כותבים ישירות לשם הקובץ הסופי
   • 3.3. מתייחסים לעצירת גודל הקובץ כסיום
   • 3.4. כולם מעדכנים קובץ משותף
   • 3.5. חושבים ש-API של נעילה הוא פתרון-על
4. שיטות עבודה מומלצות
   • 4.1. מפרסמים בסדר temp -> close -> rename / replace
   • 4.2. מציינים שלמות במפורש עם done / manifest
   • 4.3. צד הקבלה תופס claim באופן אטומי
   • 4.4. אם מסתמכים על lock file, הופכים אותו ל-lease
   • 4.5. מניחים אידמפוטנטיות מראש
5. פסאודו-קוד (קטעים)
6. חלוקה גסה בין השימושים
7. סיכום
8. מקורות

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

רוב הגורמים אינם ב-API של קלט/פלט הקבצים עצמו, אלא בכך ששלושת הדברים הבאים מעורפלים:

• מתי מותר לקרוא
• מי מחזיק בזכות העיבוד
• איך מתאוששים כשיש כישלון

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

נציין שהקוד שמופיע במאמר הזה מפורסם ב-GitHub כערכת דוגמה מלאה שאפשר לבנות ולהריץ (ספרייה, הדגמה של תחרות claim בין שני עובדים ותפיסת lease, ובדיקות יחידה ששוחזרות בהן תחרות, שחיתות נתונים ו-stale lock).

file-integration-locking-best-practices-komurasoft-style - komurasoft-blog-samples (GitHub)

1. קודם המסקנה (במשפט אחד)

• הדבר הכי חשוב בהעברת קבצים הוא ליצור מצב שבו ברגע ששם הקובץ הסופי נראה, “כבר מותר לקרוא”
• לייצג בהפרדה, באמצעות שם קובץ או תיקייה, את המצבים בתהליך יצירה / פורסם / בעיבוד / עובד
• אם יש כמה עובדים, לתפוס claim באופן אטומי לפני הקריאה
• להשתמש ב-lock file ובנעילת מערכת ההפעלה כאמצעי עזר, ובסוף לקלוט הכול באמצעות אידמפוטנטיות

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

2. תבניות התנגשות שקורות בהעברת קבצים (תרשים)

2.1. קוראים קובץ שכתיבתו טרם הושלמה

אם מתחילים לכתוב ישירות לשם הקובץ הסופי, קורית התקרית הזו. ב-JSON יחסר הסוגר הסוגר, ב-CSV יחסרו שורות, וב-ZIP הקובץ פשוט יהיה פגום.

sequenceDiagram
    accTitle: תקלת קריאת קובץ שכתיבתו לא הושלמה
    accDescr: תרשים רצף המראה שהצד השולח יוצר את הקובץ ישירות בשם הסופי וכותב אליו בהדרגה, בעוד הצד המקבל מזהה את הקובץ ומתחיל לקרוא אותו כשהוא עדיין באמצע, וכתוצאה מכך חלק מהשורות חסרות או שהניתוח נכשל.
    participant Sender as הצד השולח
    participant Share as תיקייה משותפת
    participant Receiver as הצד המקבל

    Sender->>Share: יוצר את orders.csv בשם הסופי
    Sender->>Share: כותב שורות 1 עד 5000
    Receiver->>Share: מזהה את orders.csv
    Receiver->>Share: מתחיל לקרוא כפי שהוא
    Note over Receiver: עדיין באמצע
    Sender->>Share: כותב את שאר השורות
    Note over Receiver: חוסר שורות / כישלון ניתוח / עיבוד חלקי בלבד

2.2. כמה עובדים תופסים את אותו קובץ בו-זמנית

בזרימה שבה “מסתכלים ברשימה, ואם לא עובד פותחים”, שני עובדים יכולים לתפוס את אותו קובץ. זו ההתחלה של חיוב כפול או שליחה כפולה.

sequenceDiagram
    accTitle: שני עובדים תופסים את אותו קובץ
    accDescr: תרשים רצף המראה ששני עובדים מוצאים את אותו קובץ בתיקיית incoming ומתחילים לקרוא אותו במקביל, מה שגורם לעיבוד כפול של אותו קלט.
    participant W1 as עובד 1
    participant W2 as עובד 2
    participant Dir as incoming

    W1->>Dir: מוצא את a.csv
    W2->>Dir: מוצא את a.csv
    W1->>Dir: מתחיל לקרוא
    W2->>Dir: מתחיל לקרוא
    Note over W1,W2: אותו קלט מעובד פעמיים

2.3. כולם נעצרים בגלל stale lock

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

sequenceDiagram
    accTitle: כולם נעצרים כי אי אפשר לקבוע אם ה-lock עדיין תקף
    accDescr: תרשים רצף המראה שעובד A יוצר lock ומסתיים באופן חריג, ועובד B מוצא את הקובץ, נמנע מלהתחיל לעבד וממשיך להמתין, מכיוון שאי אפשר לקבוע אם ה-lock הוא stale.
    participant A as עובד A
    participant Lock as קובץ lock
    participant B as עובד B

    A->>Lock: יוצר lock
    Note over A: מסתיים כאן באופן חריג
    B->>Lock: בודק שה-lock קיים
    B->>Lock: נמנע מלהתחיל לעבד
    B->>Lock: ממשיך להמתין
    Note over B,Lock: אי אפשר לקבוע אם זה stale, וכולם נעצרים

3. אנטי-דפוסים

3.1. בדיקה דו-שלבית של Exists -> Create

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

sequenceDiagram
    accTitle: הבדיקה הדו-שלבית מאפשרת לשני תהליכים להתקדם
    accDescr: תרשים רצף המראה שתהליך A ותהליך B בודקים שניהם שאין lock, שניהם מקבלים תשובה שאין, ולכן שניהם יוצרים lock ומתקדמים בו-זמנית.
    participant A as תהליך A
    participant B as תהליך B
    participant FS as מערכת הקבצים

    A->>FS: בודק שאין lock
    B->>FS: בודק שאין lock
    FS-->>A: אין
    FS-->>B: אין
    A->>FS: יוצר lock
    B->>FS: יוצר lock
    Note over A,B: שניהם מצליחים להתקדם

דוגמה טיפוסית לא טובה נראית כך.

if (!File.Exists(lockPath))
{
    File.WriteAllText(lockPath, Environment.ProcessId.ToString());
    ProcessFile();
}

מה שנדרש הוא להפוך את “אם אין - ליצור” לפעולה אחת. ב-‎.NET משתמשים במשפחת FileMode.CreateNew, ובמערכות POSIX ביצירה אטומית כמו O_CREAT | O_EXCL.

3.2. כותבים ישירות לשם הקובץ הסופי

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

flowchart LR
    accTitle: הכשל שנגרם מכתיבה ישירה לשם הסופי
    accDescr: תרשים המראה שברגע ששם הקובץ הסופי נראה, צד הקבלה מזהה אותו בעוד צד השליחה עדיין באמצע כתיבה, וכתוצאה מכך נקראים נתונים לא שלמים.
    A["שם final נראה"] --> B["צד הקבלה מזהה"]
    B --> C["צד השליחה עדיין כותב"]
    C --> D["נקראים נתונים לא שלמים"]

using var writer = OpenForWrite(finalPath); // כאן finalPath כבר נראה
foreach (var row in rows)
{
    writer.WriteLine(row);
}

השיטה הזו מזמינה בעצמה את התקרית מסעיף 2.1.

3.3. מתייחסים לעצירת גודל הקובץ כסיום

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

sequenceDiagram
    accTitle: זיהוי שגוי של סיום לפי התייצבות גודל הקובץ
    accDescr: תרשים רצף המראה שהצד השולח מתחיל להעתיק קובץ ומשתהה לרגע באמצע, בעוד צד הקבלה רואה שהגודל לא השתנה 10 שניות ומזהה זאת בטעות כסיום ומתחיל לקרוא, בעוד ההעתקה עדיין לא הושלמה.
    participant Sender as הצד השולח
    participant Share as תיקייה משותפת
    participant Receiver as הצד המקבל

    Sender->>Share: מתחיל להעתיק את data.zip
    Sender->>Share: משתהה זמנית באמצע
    Receiver->>Share: הגודל לא משתנה 10 שניות
    Note over Receiver: מזהה בטעות כסיום
    Receiver->>Share: מתחיל לקרוא
    Sender->>Share: ממשיך בהעתקה

if (currentLength == lastLength && stableSeconds >= 10)
{
    return Ready;
}

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

3.4. כולם מעדכנים קובץ משותף

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

sequenceDiagram
    accTitle: עדכון הדדי בקובץ משותף מאבד עדכון
    accDescr: תרשים רצף המראה שאצווה A ואצווה B שתיהן קוראות את אותה גרסה v1 של status.csv וכל אחת כותבת גרסה משלה, כשגרסה B נכתבת אחרונה ומוחקת את העדכון של A.
    participant A as אצווה A
    participant B as אצווה B
    participant F as status.csv

    A->>F: קורא v1
    B->>F: קורא v1
    A->>F: כותב v2-A
    B->>F: כותב v2-B
    Note over F: העדכון של A נעלם

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

3.5. חושבים ש-API של נעילה הוא פתרון-על

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

הערה:

• ‏flock ב-Linux הוא advisory lock, ולכן אפשר בקלות לכתוב צד שמתעלם מההסכם
• ‏byte-range lock ב-Windows מתעלם ממנו כשמדובר בקובץ ממופה לזיכרון
• כלומר, עדיף לא להטיל על נעילת מערכת ההפעלה לבדה גם את התכנון של הודעת סיום ובעלות

הנקודה השנייה מפורשת במפרט של Windows. ב-Locking and Unlocking Byte Ranges in Files של Microsoft Learn, מיד אחרי המשפט שגישה של תהליך אחר לטווח נעול תמיד תיכשל (כלומר נעילת הטווח ב-Windows אינה advisory אלא נאכפת), מופיעה הערה שכאשר משתמשים בקובץ ממופה לזיכרון, ה-byte-range lock מתעלם ממנה. אם הצד השני נוגע באותו קובץ דרך CreateFileMapping, הנעילה שלכם פשוט לא רלוונטית עבורו.

אם רוצים לתפוס נעילת טווח ב-‎.NET, זה FileStream.Lock / Unlock (במקרה של Windows).

using var stream = new FileStream(
    path, FileMode.Open, FileAccess.ReadWrite, FileShare.ReadWrite);

// נועלים באופן בלעדי רק את הבייט הראשון, כ"תג" של בעיבוד
stream.Lock(0, 1);
try
{
    // כאן מתבצעת הקריאה/כתיבה של הגוף עצמו
}
finally
{
    // תמיד משחררים לפני הסגירה
    stream.Unlock(0, 1);
}

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

4. שיטות עבודה מומלצות

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

4.1. מפרסמים בסדר temp -> close -> rename / replace

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

flowchart TD
    accTitle: חמשת השלבים של פרסום בטוח
    accDescr: תרשים המראה את חמשת השלבים של פרסום בטוח - יצירת שם temp ייחודי, כתיבת כל התוכן ל-temp, ביצוע flush/close, rename/replace לשם final באותה תיקייה, וצד הקבלה עוקב רק אחרי שם final.
    A["יוצרים שם temp ייחודי"] --> B["כותבים את כל התוכן ל-temp"]
    B --> C["מבצעים flush / close"]
    C --> D["מבצעים rename / replace לשם final באותה תיקייה"]
    D --> E["צד הקבלה עוקב רק אחרי שם final"]

נקודות מרכזיות:

• ‏temp ו-final נמצאים באותה תיקייה, לפחות באותו כרך / מערכת קבצים
• ב-Windows / ‎.NET אפשר לשקול את משפחת File.Replace
• ההסכם הוא שברגע ששם final נראה, התוכן כבר הושלם

אם temp נמצא בכונן אחר, ה-rename עלול להיות שקול להעתקה בלבד, או ש-Replace עלול להיכשל. ההנחה הזו נראית לא בולטת, אבל היא חשובה מאוד.

דרך תיקייה משותפת (SMB), עוד ארבע נקודות מתנודדות. זה בדיוק שדה הקרב המרכזי של המאמר הזה, ולכן נכתוב אותן בנפרד.

• ‏rename בתוך אותה תיקייה של אותו שיתוף מתבצע בצד השרת. ולכן התכונה של “לא נראה שם ביניים” נשמרת כפי שהיא. לעומת זאת, כשחוצים שיתופים, כמו מ-\\server\shareA ל-\\server\shareB, זה נחשב לכרך נפרד, וכאשר MoveFileEx ב-Windows מקבל MOVEFILE_COPY_ALLOWED, הוא מחליף את המעבר בהעתקה ומחיקה. כלומר זה מפסיק להיות אטומי, ונראה מצב ביניים. ההנחה שממקמים את temp ו-final, ואת incoming ו-processing, בתוך אותו שיתוף, חשובה עוד יותר מאשר במצב מקומי
• ‏rename נכשל רק בגלל ש”מישהו פותח את הקובץ”. לתיקייה משותפת ניגשים גורמים שלא הכרתם, כמו אנטי-וירוס, מנוע אינדוקס לחיפוש, או לקוחות מסניפים אחרים. מעשי להתייחס לכישלון rename של publish ו-claim לא כחריגה אלא כענף רגיל, עם המתנה קצרה וניסיון חוזר
• חותמת הזמן לא יכולה לשמש כלי החלטה. ב-File Times של Microsoft Learn כתוב שמה שמובטח לגבי זמני קובץ הוא רק ש”הוא ישקף נכון את השינוי בזמן שסוגרים את ה-handle שביצע אותו”. זמן העדכון האחרון בזמן כתיבה לא מתעדכן במלואו עד שכל ה-handle-ים לכתיבה נסגרים. גם הגרנולריות תלויה במערכת הקבצים - זמן העדכון האחרון ב-FAT מתעדכן ביחידות של 2 שניות, וזמן הגישה האחרון ב-NTFS מתעדכן באיחור של עד שעה. בנוסף, דרך SMB הזמן מסומן לפי שעון השרת, ולכן אם יש הפרש בין שעון הלקוח לשרת, גם קביעה כמו “לעבד N דקות אחרי העדכון” תתעוות בהתאם. זו הסיבה שקביעת סיום לא נעשית לפי זמן או גודל, אלא עם done / manifest מסעיף 4.2
• גם התראות שינוי מפספסות. לא כדאי להסתמך רק על התראות אירועים לניטור תיקייה משותפת - שילוב עם סריקת ספרייה מחזורית מייצב את זה. הנושא הזה מסוכם ב-מדריך מעשי ל-FileSystemWatcher — התמודדות עם פספוסים וכפילויות

4.2. מציינים שלמות במפורש עם done / manifest

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

flowchart TD
    accTitle: זרימת פרסום עם done ומעקב manifest
    accDescr: תרשים המראה שיוצרים data.tmp, מפרסמים אותו כ-data.csv, יוצרים את data.done או manifest.json, צד הקבלה מזהה את קובץ ה-done או ה-manifest, ומאמת שם קובץ, גודל ו-hash.
    A["יוצרים את data.tmp"] --> B["מפרסמים כ-data.csv"]
    B --> C["יוצרים data.done / manifest.json"]
    C --> D["צד הקבלה מזהה done / manifest"]
    D --> E["מאמתים שם קובץ, גודל ו-hash"]

הפריטים שכדאי לכלול ב-manifest הם בערך אלה.

• שם הקובץ הרלוונטי
• גודל
• hash
• מספר רשומות
• מזהה העברה / idempotency key
• זמן יצירה

גם הסדר חשוב. אם done מונח לפני פרסום גוף הנתונים, זו לא הודעת סיום אלא הודעה מוקדמת על תקרית.

4.3. צד הקבלה תופס claim באופן אטומי

אם כמה עובדים מסתכלים על אותו incoming, קל להבין את הגישה של “להעביר לעצמך לפני שקוראים”. רק העובד שהצליח לבצע rename מ-incoming ל-processing/<worker>/ מעבד.

sequenceDiagram
    accTitle: רק העובד שמצליח ב-rename תופס בעלות
    accDescr: תרשים רצף המראה ששני עובדים מוצאים את אותו קובץ ומנסים לבצע rename ל-processing, כשרק מי שמצליח ראשון תופס בעלות על העיבוד.
    participant W1 as עובד 1
    participant W2 as עובד 2
    participant IN as incoming
    participant PR as processing

    W1->>IN: מוצא את a.csv
    W2->>IN: מוצא את a.csv
    W1->>PR: מבצע rename ל-a.csv
    W2->>PR: מבצע rename ל-a.csv
    Note over W1,W2: רק מי שהצליח ראשון תופס בעלות

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

flowchart LR
    accTitle: מסלול התיקיות מ-temp עד archive או error
    accDescr: תרשים המראה שקובץ עובר מ-temp דרך פרסום ל-incoming, משם דרך claim ל-processing, ולבסוף בהצלחה ל-archive או בכישלון ל-error.
    T["temp"] -->|"פרסום"| I["incoming"]
    I -->|"claim"| P["processing"]
    P -->|"הצלחה"| A["archive"]
    P -->|"כישלון"| E["error"]

גם ה-rename עבור ה-claim, ההנחה היא שהוא מתבצע על אותה מערכת קבצים.

4.4. אם מסתמכים על lock file, הופכים אותו ל-lease

אם משתמשים ב-lock file, כדאי שהוא יהיה מידע בעלות עם תוקף, ולא רק קובץ ריק. ‏lock שלא ברור מי תפס אותו, בהכרח יגרום לבעיות בהמשך.

flowchart TD
    accTitle: השדות של קובץ ה-lease ב-lock.json
    accDescr: תרשים המראה שקובץ lock.json מכיל שישה שדות - ownerId, host, pid, acquiredAt, expiresAt ו-heartbeatAt.
    L["lock.json"] --> A["ownerId"]
    L --> B["host"]
    L --> C["pid"]
    L --> D["acquiredAt"]
    L --> E["expiresAt"]
    L --> F["heartbeatAt"]

נקודות מרכזיות:

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

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

4.5. מניחים אידמפוטנטיות מראש

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

flowchart LR
    accTitle: תהליך שמניח אידמפוטנטיות
    accDescr: תרשים המראה שקלט עם idempotency key נבדק אם כבר עובד, ואם כן מטופל כהצלחה בלי ריצה כפולה, ואם לא - מתבצע העיבוד ונרשם ביומן העיבודים.
    A["קלט + idempotency key"] --> B{"כבר עובד?"}
    B -->|"כן"| C["מתייחסים כהצלחה בלי ריצה כפולה"]
    B -->|"לא"| D["מבצעים את העיבוד"]
    D --> E["רושמים ביומן העיבודים"]

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

5. פסאודו-קוד (קטעים)

‏MakeTempPathSameDirectory ו-TryClaimBundleByRename שמופיעים כאן הם שמות פונקציה בדיוניים שמוצגים כדי להראות את הסדר. המימוש שבאמת פועל נמצא בערכת הדוגמה שהוצגה בפתיחה.

המימוש של הפסאודו-קוד הזה (ספרייה, הדגמת תחרות claim בין שני עובדים, בדיקות יחידה) - komurasoft-blog-samples (GitHub)

5.1. תבנית כשל טיפוסית

var lockPath = finalPath + ".lock";

if (!File.Exists(lockPath))
{
    File.WriteAllText(lockPath, "");
    using var writer = OpenForWrite(finalPath); // כותב ישירות לשם הסופי
    WritePayload(writer);

    File.Delete(lockPath);
}

יש שלוש בעיות.

• ‏Exists ו-WriteAllText הן שתי פעולות נפרדות
• ‏finalPath נראה כבר באמצע הכתיבה
• ‏lock נשאר בסיום חריג

5.2. דוגמה לכיוון נכון (בגדול, ככה)

var tempPath = MakeTempPathSameDirectory(finalPath);
WritePayload(tempPath);
FlushAndClose(tempPath);

PublishByRenameOrReplace(tempPath, finalPath); // בהנחת אותה מערכת קבצים / אותו volume
PublishDoneFile(finalPath + ".done", new
{
    FileName = Path.GetFileName(finalPath),
    Size = GetFileSize(finalPath),
    Hash = ComputeHash(finalPath),
    IdempotencyKey = integrationId
});

if (!TryClaimBundleByRename(baseName, incomingDir, processingDir))
{
    return; // עובד אחר תפס קודם
}

var manifest = ReadDoneFile(Path.Combine(processingDir, baseName + ".done"));
VerifyPayload(Path.Combine(processingDir, baseName), manifest);

if (AlreadyProcessed(manifest.IdempotencyKey))
{
    MoveBundle(processingDir, archiveDir, baseName);
    return;
}

Process(Path.Combine(processingDir, baseName));
RecordProcessed(manifest.IdempotencyKey);
MoveBundle(processingDir, archiveDir, baseName);

כאן הסדר חשוב יותר מפרטי המימוש. כשלא מערבבים “לכתוב”, “לפרסם”, “לתפוס בעלות” ו”לתעד עיבוד” - זה נשבר פחות.

6. חלוקה גסה בין השימושים

• עם writer יחיד, reader יחיד ואותה מכונה, גם temp -> rename בלבד כבר יציב למדי
• אם יש כמה consumer, מוסיפים claim rename מ-incoming ל-processing
• בשילוב בין מערכות שונות, NAS או תיקייה משותפת, בטוח יותר להוסיף גם manifest / done וגם אידמפוטנטיות
• אם כמה writer רוצים לעדכן את אותו מצב לוגי, כדאי לשקול מסד נתונים או תור, ולא להתאמץ יתר על המידה עם העברת קבצים
• נעילת מערכת ההפעלה יעילה בתוך אותה קבוצת אפליקציות ואותן הנחות, אבל היא לא תחליף לפרוטוקול מסירה

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

7. סיכום

בקרת הרשאות בלעדיות בהעברת קבצים היא לא קריאה לפונקציית נעילה, אלא קביעת מעברי מצב. זה עצם הרעיון של המאמר הזה. מייצגים בשם או בתיקייה את המצבים בתהליך יצירה / פורסם / בעיבוד / עובד, ונמנעים מבדיקה דו-שלבית של Exists -> Create, מכתיבה ישירה לשם הקובץ הסופי, מהמתנה להתייצבות גודל, מעדכון הדדי של קובץ משותף, ומהסתמכות יתר על API של נעילה. מעבר לכך, שילוב של temp -> close -> rename / replace,‏ done / manifest,‏ claim rename,‏ lease ואידמפוטנטיות מונע תקריות רבות בהעברת קבצים דרך תיקיות משותפות.

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

8. מקורות

• ערכת קוד הדוגמה המלאה של המאמר הזה (ספרייה, הדגמה, בדיקות יחידה) - komurasoft-blog-samples (GitHub)
• LockFileEx function (Win32)
• Locking and Unlocking Byte Ranges in Files (Win32)
• Moving and Replacing Files (Win32)
• MoveFileEx function (Win32)
• File Times (Win32)
• FileStream.Lock Method (.NET)
• File.Replace Method (.NET)
• rename — POSIX
• open — POSIX (O_CREAT | O_EXCL)
• flock(2) — Linux manual page
• open(2) — Linux manual page

מאמרים קשורים

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

נושאים קשורים

העמודים האלה ממקמים את הנושא בהקשר רחב יותר של שירותים והחלטות.

שירותים הקשורים לנושא הזה

המאמר קשור ישירות לשירותים הבאים.

שאלות נפוצות

שאלות נפוצות בפניות בנושא המאמר.

האם בקרת ההרשאות הבלעדיות בהעברת קבצים מספיקה עם API של נעילה בלבד?

לעיתים קרובות זה לא מספיק. flock ב-Linux הוא advisory lock, ולכן אפשר בקלות לכתוב תוכנית שמתעלמת מההסכם, ו-byte-range lock ב-Windows מתעלם ממנו כאשר מדובר בקובץ ממופה לזיכרון. נעילת מערכת ההפעלה יעילה בתוך אותה קבוצת אפליקציות ואותן הנחות, אבל כדאי להשתמש בה כאמצעי עזר, ולהפוך את תכנון פרוטוקול המסירה - temp -> rename,‏ done/manifest,‏ claim אטומי ואידמפוטנטיות - לגוף העיקרי.

איך נמנעים מכך שיקראו קובץ שכתיבתו טרם הושלמה?

הדרך הסטנדרטית היא לפרסם בסדר temp -> close -> rename/replace. סוגרים את הקובץ בשלב היצירה תחת שם temp, ואחרי ה-close מחליפים לשם הסופי (final) באותה תיקייה, כשצד הקבלה מסתכל רק על השם הסופי. ה-temp וה-final חייבים להיות באותה תיקייה, לפחות באותו כרך/מערכת קבצים, וההסכם הוא שברגע שהשם הסופי נראה - התוכן כבר הושלם.

איך מונעים מכמה עובדים לעבד את אותו קובץ בו-זמנית?

תופסים את ה-claim באופן אטומי לפני הקריאה. באופן קונקרטי, רק העובד (worker) שהצליח לבצע rename מ-incoming ל-processing/<worker>/ הוא זה שמעבד. בדיקה דו-שלבית של Exists ואחריה Create אינה יוצרת בלעדיות, כי ה"בדיקה" וה"תפיסה" הן שתי פעולות נפרדות שתהליך אחר יכול להתפרץ ביניהן. אם נדרשת יצירה אטומית, משתמשים ב-FileMode.CreateNew של ‎.NET או ב-O_CREAT | O_EXCL של POSIX.

האם יש נקודות לתשומת לב כשמשתמשים ב-lock file?

כדאי להפוך אותו לא לקובץ ריק פשוט, אלא ל-lease (מידע בעלות) עם תוקף, שמכיל ownerId,‏ host,‏ pid,‏ acquiredAt,‏ expiresAt ו-heartbeatAt. היצירה מתבצעת באופן אטומי, הפסקת עדכונים משמשת אינדיקציה ל-stale, המחיקה מתבצעת בעיקרון רק על ידי היוצר, ומכינים מראש נהלי התאוששות בהנחה שיש דליפות של אי-שחרור. בפועל בשטח, עדיף לא לנסות להבטיח שלמות מלאה עם קובץ נעילה אחד בלבד, אלא לתכנן כך שבסוף האידמפוטנטיות תקלוט את זה.

פרופיל הכותב

עמוד היכרות עם כותב המאמר.

Go Komura

מנהל KomuraSoft LLC

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