OneDrive Files On-Demand ואפליקציות עסקיות — placeholders שוברים הנחות

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

כשחוקרים, הסיבה לעיתים קרובות אינה באג באפליקציה אלא “גיבוי אוטומטי של Desktop ו-Documents” של OneDrive (Known Folder Move, KFM) ו-Files On-Demand. ה-Desktop האמיתי עבר אל C:\Users\<name>\OneDrive\Desktop, וחלק מהקבצים שרואים שם הם placeholders בלי תוכן מקומי. משתמשים ו-IT ממשיכים להשתמש במחשב בלי להבחין בשינוי.

במילים אחרות, ההנחה הסמויה של אפליקציה עסקית ש«הקובץ יושב בדיסק המקומי» הוחלפה, בלי שאף אחד החליט על כך, בהנחה ש«הקובץ בענן, ומקומית יש רק את המראה». המאמר מיועד לאנשי IT בעסקים קטנים ובינוניים ולמפתחי Windows. הוא מסדר, לפי מקורות ראשוניים של Microsoft Learn, איך placeholders עובדים, איך לזהות מצב מ-file attributes, המלכודות הטיפוסיות שאפליקציה עסקית דורכת בהן, מה צד הפיתוח וצד ה-IT יכולים לעשות, ואיך ממיינים כשאומרים לכם «הקובץ לא נפתח».

flowchart TB
    accTitle: החלפת ההנחה הסמויה של אפליקציה עסקית
    accDescr: ההנחה הסמויה של אפליקציה עסקית שהקובץ יושב בדיסק המקומי הוחלפה בלי שאף אחד החליט על כך בהנחה שהתוכן האמיתי בענן ומקומית יש רק את המראה
    before["ההנחה הסמויה המסורתית"] --> b1["תוכן אמיתי בדיסק המקומי"]
    after["ההנחה שהוחלפה"] --> a1["התוכן האמיתי בענן"]
    a1 --> a2["מקומית יש רק את המראה"]
    a2 -.-> note["Placeholder"]

איור 1: ההנחה ש«התוכן האמיתי מקומי» הוחלפה, בלי שאף אחד החליט על כך, ב-«התוכן האמיתי בענן; מקומית יש רק את המראה».

1. קודם כל, המסקנות

• Desktop, Documents ו-Pictures אולי הועברו תחת C:\Users\<name>\OneDrive\ על ידי KFM. זה נוטה להידלק בהקמה הראשונית של מחשב חדש, וארגון יכול גם להחיל זאת בכמות גדולה במדיניות. אפליקציה שמניחה נתיב קבוע נשברת כאן.¹
• Files On-Demand דלוק כברירת מחדל באפליקציית הסנכרון הנוכחית. קבצים שנוצרו במכשיר אחר או באינטרנט מופיעים כ-placeholders במצב «online-only» בלי תוכן מקומי.²³
• Placeholder הוא reparse point שמנוהל על ידי Cloud Files API (ה-minifilter cldflt.sys). הוא נראה כקובץ רגיל ל-Explorer ול-file APIs, ופתיחתו מורידה (hydration) אוטומטית.⁴
• אפשר לזהות מצב מ-file attributes. FILE_ATTRIBUTE_OFFLINE, RECALL_ON_DATA_ACCESS, PINNED, UNPINNED וכדומה הם הסימנים, ופקודת attrib מציגה אותם כאותיות O, P ו-U. בדיקת attributes בלבד אינה גורמת להורדה.⁵⁶⁷
• תאונות טיפוסיות באפליקציה עסקית הן שילוב של «לא נפתח», «איטי», «attributes נקראו לא נכון», «סערת אירועי watch» ו-«קונפליקט עם סנכרון». Offline או כש-OneDrive נעצר, hydration נכשל, ותהליך batch משרה הורדה של כל קובץ.⁴⁸
• תגובת צד האפליקציה היא «לכבד placeholders». הבסיס הוא לזהות לפי attributes בזמן enumerate ולא לפתוח בפזיזות, להשתמש ב-FILE_FLAG_OPEN_NO_RECALL אם צריך, ולא לשים את תיקיית הנתונים תחת OneDrive.⁹¹⁰
• תגובת צד ה-IT היא «pin לתיקיות העסקיות» ו-«שליטה במדיניות». הבטיחו תוכן מקומי לתיקיות עסקיות עם «Always keep on this device», והגדירו KFM ו-Files On-Demand במכוון עם Group Policy / Intune. אל תשכחו ש-Storage Sense יכול גם «להחזיר קבצים שאינם בשימוש ל-online-only».¹¹¹²

במשפט אחד: «קובץ שנראה ב-Explorer» ו-«קובץ שיש לו תוכן אמיתי בדיסק המקומי» כבר אינם אותו דבר.

2. מה קורה — KFM ו-Files On-Demand

2.1. Desktop אולי כבר אינו C:\Users\<name>\Desktop

לאפליקציית הסנכרון של OneDrive יש תכונה בשם Known Folder Move (KFM). במסך ההגדרות היא מוצגת כ-«Backup», «Back up important folders» וכדומה; כשהיא דלוקה, התוכן האמיתי של Desktop, Documents ו-Pictures מועבר (redirect) תחת תיקיית OneDrive.¹

בהקמה הראשונית (OOBE) של מחשב חדש, כניסה עם Microsoft account או work account מציגה בהרחבה גיבוי תיקיות כהצעת ברירת מחדל, והמשך כפי שהוא מדליק אותה. ארגון יכול גם להחיל זאת בכמות גדולה בלי לשאול את המשתמש דבר, עם המדיניות «Silently move Windows known folders to OneDrive» (KFMSilentOptIn).¹¹¹

flowchart TB
    accTitle: שני מסלולים שבהם KFM נדלק
    accDescr: כניסה עם חשבון בהקמה הראשונית של מחשב חדש מציגה גיבוי תיקיות כהצעת ברירת מחדל והמשך כפי שהוא מדליק אותה; בארגון מדיניות KFMSilentOptIn מחילה זאת בכמות גדולה בלי לשאול את המשתמש
    oobe["הקמה ראשונית של מחשב חדש"] --> signin["כניסה עם חשבון"]
    signin --> prompt["גיבוי מוצע כברירת מחדל"]
    prompt --> on1["המשך כפי שהוא מדליק"]
    org["מדיניות הארגון"] --> silent["KFMSilentOptIn"]
    silent --> on2["מוחל בכמות גדולה בלי לשאול"]
    on1 --> kfm["KFM דלוק"]
    on2 --> kfm

איור 2: KFM נדלק בלי שאף אחד שם לב, בין בהצעת ברירת המחדל בהקמה הראשונית ובין במדיניות ההחלה השקטה של הארגון.

החלק המביך הוא שהמראה ב-Explorer כמעט אינו משתנה. APIs של known folders ב-shell (SHGetKnownFolderPath ו-Environment.GetFolderPath של .NET) מחזירים את הנתיב הנכון אחרי ההעברה, כך שאפליקציה מנומסת ממשיכה לעבוד. מה שנשבר הוא אפליקציה שמשבצת נתיב קבוע כמו C:\Users\%USERNAME%\Desktop בקובץ הגדרות או בקוד. הדפוס הטיפוסי של ייבוא שנכשל ב-«הקובץ לא נמצא» אחרי החלפת מחשב הוא זה.

flowchart TB
    accTitle: התנהגות פתרון הנתיב של אפליקציה אחרי KFM
    accDescr: אחרי ש-KFM מעביר את Desktop האמיתי ותיקיות דומות תחת OneDrive, אפליקציה שמשתמשת ב-known folder APIs ממשיכה לעבוד עם הנתיב הנכון אחרי ההעברה, אבל אפליקציה שמשבצת נתיב קבוע נכשלת בקובץ לא נמצא
    kfm["KFM נדלק"] --> move["Desktop האמיתי ודומים עוברים תחת OneDrive"]
    move --> how{"איך האפליקציה פותרת את הנתיב?"}
    how -->|Known folder APIs| ok["מקבל את הנתיב הנכון אחרי ההעברה וממשיך לעבוד"]
    how -->|נתיב קבוע מקודד| ng["הקובץ לא נמצא"]

איור 3: אחרי KFM, אפליקציה שמשתמשת ב-known folder APIs ממשיכה לעבוד, אבל אפליקציה שמקודדת נתיב קבוע נשברת כאן.

2.2. Files On-Demand — נראים, אבל בלי תוכן אמיתי

החוט השני הוא Files On-Demand. בסביבה שבה הם דלוקים, כל קובץ ב-OneDrive נראה ב-Explorer, אבל התוכן אינו מורד עד שהקובץ נפתח. התכונה דלוקה כברירת מחדל באפליקציית הסנכרון הנוכחית, ו-Microsoft גם ממליצה להשאיר אותה דלוקה.²³

אפשר לקרוא מצב מאייקוני הסטטוס ב-Explorer.¹³

החשוב כאן הוא המצב האמצעי. קובץ שנפתח פעם ויש לו עכשיו תוכן מקומי יכול לחזור ל-online-only דרך פעולת «Free up space» של המשתמש או דרך Storage Sense, שיידון בהמשך. זה אחד הגורמים לתקלה שקשה לשחזר מסוג «בחודש שעבר זה עבד».³¹²

stateDiagram-v2
    accTitle: שלושת מצבי Files On-Demand והמעברים
    accDescr: קובץ online-only הופך ל-locally available בפתיחה, אבל Free up space או Storage Sense יכולים להחזיר אותו ל-online-only, ורק קובץ pinned נמצא מחוץ לשחרור אוטומטי
    s1: Online-only (סימן ענן)
    s2: Locally available
    s3: Pinned (Always keep on this device)
    s1 --> s2: פתיחה (hydration)
    s2 --> s1: Free up space
    s2 --> s1: Storage Sense
    s1 --> s3: Always keep on this device
    s2 --> s3: Always keep on this device
    s3 --> s2: Unpin

איור 4: שלושת מצבי Files On-Demand. «Locally available» יכול לחזור אוטומטית ל-online-only; pin מחוץ לזה.

3. מה placeholder באמת — Cloud Files API ו-reparse points

Files On-Demand מיושם מעל מנגנון OS שהוצג ב-Windows 10 version 1709, Cloud Files API. יחידת העבודה בצד מערכת הקבצים היא minifilter בשם cldflt.sys (שם השירות CldFlt, «Windows Cloud Files Filter Driver»), ו-OneDrive הוא אחד מ-«sync providers» שמשתמשים ב-API הזה.⁴⁷

Placeholder מבחינה טכנית הוא reparse point. במערכת הקבצים קיימים רק metadata כמו שם, גודל ו-timestamps (כ-1KB); אין נתוני תוכן. כשהאפליקציה פותחת את הקובץ וקוראת, ה-minifilter מזהה את הבקשה, מורה ל-sync provider להעביר את הנתונים, ממתין לסיום ההורדה, ואז הקריאה ממשיכה. השליפה הזו נקראת hydration; השלכת התוכן המקומי וחזרה ל-placeholder נקראת dehydration.⁴

sequenceDiagram
    accTitle: Hydration כש-placeholder נפתח
    accDescr: כשאפליקציה פותחת placeholder וקוראת, ה-minifilter cldflt.sys מזהה את הבקשה, מורה ל-sync provider להעביר נתונים, ממתין לסיום ההורדה, ואז הקריאה ממשיכה
    participant app as אפליקציה עסקית
    participant flt as Minifilter cldflt.sys
    participant sync as Sync provider
    app->>flt: בקשת פתיחה וקריאה
    flt->>sync: הוראה להעברת נתונים
    sync-->>flt: ההורדה הושלמה
    flt-->>app: הקריאה ממשיכה

איור 5: קריאת placeholder ממשיכה אחרי שה-minifilter גורם ל-sync provider לשלוף את הנתונים.

שמיעת «reparse point» מדאיגה לגבי תאימות לקוד קיים ש«מטפל ב-reparse point במיוחד אם הוא מזהה אחד», אבל לשם תאימות Cloud Files API מסתיר שזה reparse point מכולם מלבד מנוע הסנכרון ותהליכים תחת %systemroot%. מאפליקציה רגילה זה נראה כ-«קובץ רגיל שרק קצת איטי בפתיחה». השקיפות היסודית הזו, לצד הנוחות, היא גם הסיבה ש«האפליקציה מקבלת את הנחותיה שבורות בלי להבחין».⁴ מנגנון reparse points עצמו מוסבר ב-«NTFS Internals».

flowchart TB
    accTitle: הסתרת ה-reparse point וההבדל במראה
    accDescr: Placeholder הוא reparse point, אבל Cloud Files API מסתיר זאת מתהליכים שאינם מנוע הסנכרון, ולכן מאפליקציה רגילה זה נראה כקובץ רגיל שרק קצת איטי בפתיחה
    ph["Placeholder (reparse point)"] --> who{"איזה process פתח?"}
    who -->|מנוע הסנכרון וכדומה| raw["נראה כ-reparse point"]
    who -->|כל אפליקציה אחרת| plain["נראה כקובץ רגיל"]
    plain -.-> note["נראה רק קצת איטי בפתיחה"]

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

במאפייני Explorer, ל-placeholder יש מראה אופייני ש«Size» מציג את הגודל המקורי, בעוד «Size on disk» כמעט 0. ההנחה «יש לו גודל, אז חייב להיות תוכן אמיתי» אינה מחזיקה כאן.

flowchart TB
    accTitle: איך placeholder נראה במאפיינים
    accDescr: במאפייני Explorer placeholder מציג את הגודל המקורי כ-Size בעוד Size on disk כמעט 0, כך שההנחה שיש לו גודל ולכן חייב להיות תוכן אמיתי אינה מחזיקה
    prop["מאפייני placeholder"] --> size["Size הוא הגודל המקורי"]
    prop --> disk["Size on disk כמעט 0"]
    size -.-> trap["ההנחה שחייב להיות תוכן אמיתי"]
    disk -.-> truth["אין תוכן מקומי"]

איור 7: Placeholder מציג את הגודל המקורי כ-«Size» בעוד «Size on disk» כמעט 0.

4. File attributes מספרים את המצב

מצב placeholder מפורסם כ-file attributes רגילים. העיקריים כדלקמן.⁵

פקודת attrib ב-command prompt יכולה להציג ולהגדיר אלה כאות אחת. O היא תכונת offline, P pinned, U unpinned.⁶ ההתאמה למצב Files On-Demand של OneDrive מסודרת בתיעוד Microsoft כך.⁷

אזהרה אחת. החלפת מצב יש לה סדר. כשרוצים שקובץ online-only (U) יהפוך ל-«locally available», הרצת -p לבדה משאירה את U דלוק והתוכן האמיתי אינו נשלף. התיעוד של Microsoft גם מציג את הנוהל של קודם +p (always available) כדי להוריד את התוכן האמיתי ואז -p.⁷ בסקריפט שחייב להחליף מצב קיים באמינות, בטוח יותר לנקות את התכונה הנגדית באותו זמן, כמו attrib +p -u.

flowchart TB
    accTitle: סדר המעבר מ-online-only ל-locally available
    accDescr: הרצת attrib -p לבדה על קובץ online-only משאירה את תכונת U והתוכן האמיתי אינו נשלף; צריך את הנוהל של קודם להוריד את התוכן האמיתי עם attrib +p ואז -p
    u["Online-only (U)"] -->|רק attrib -p| stay["נשאר U; התוכן האמיתי אינו נשלף"]
    u -->|attrib +p| pin["Pinned (הורד את התוכן האמיתי)"]
    pin -->|attrib -p| local["Locally available"]

איור 8: מעבר מ-online-only דורש את הסדר של קודם לשלוף את התוכן האמיתי עם +p ואז -p.

דוגמה לזיהוי ב-PowerShell. הסתכלות ב-attributes בלבד אינה גורמת ל-hydration, ולכן אפשר להשתמש בזה בביטחון לחקירה ובדיקות המוניות.

function Test-CloudPlaceholder {
    param([Parameter(Mandatory)][string]$Path)

    $value = [int](Get-Item -LiteralPath $Path -Force).Attributes

    [pscustomobject]@{
        Path               = $Path
        Offline            = ($value -band 0x00001000) -ne 0  # FILE_ATTRIBUTE_OFFLINE
        RecallOnDataAccess = ($value -band 0x00400000) -ne 0  # לא כל התוכן מקומי
        Pinned             = ($value -band 0x00080000) -ne 0  # Always keep on this device
        Unpinned           = ($value -band 0x00100000) -ne 0  # Online-only
    }
}

# בדיקה המונית של CSV תחת תיקיית Documents (התוכן אינו מורד).
# פתרו את הנתיב עם known folder API. קידוח שם התצוגה
# "Documents" יכול להפוך לנתיב שאינו קיים לפי שם התיקייה האמיתי
# (Documents מול שם מקומי) ותצורת KFM
Get-ChildItem ([Environment]::GetFolderPath('MyDocuments')) -Recurse -Filter *.csv |
    ForEach-Object { Test-CloudPlaceholder $_.FullName } |
    Where-Object RecallOnDataAccess |
    Format-Table -AutoSize

ההמרה ל-[int] היא כי enumeration של FileAttributes ב-.NET אינו מגדיר שמות כמו RECALL_ON_DATA_ACCESS. פעולות bitwise על הערך המספרי יכולות לזהות בלי קושי.

5. מלכודות שאפליקציה עסקית דורכת בהן

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

5.1. פתיחה מתחילה הורדה אוטומטית — «לא נפתח» ב-offline

פתיחת קובץ online-only מתחילה hydration במקום. אונליין ועל קובץ קטן זה מהיר עד שכמעט לא שמים לב, אבל כש-OneDrive נעצר, המשתמש signed out, או הסנכרון מושהה, כשהרשת לא בריאה, או כשהקובץ גדול, מקבלים «קובץ שקיים אבל לא נפתח». השגיאה יכולה לחזור כקוד cloud-file כמו ERROR_CLOUD_FILE_PROVIDER_NOT_RUNNING (0x8007016A, «The cloud file provider is not running»), או להיראות מצד האפליקציה כ-timeout.⁸

עוד מלכודת: בדיקת קיום בסגנון File.Exists(), וקבלת attributes וגודל, מצליחות. מקבלים דפוס שגיאה שאין לו הסבר בתחושת דיסק מקומי: «בדיקת הקיום עברה, הקריאה נכשלה».

flowchart TB
    accTitle: פיצול הגישה לקובץ online-only
    accDescr: בדיקת קיום וקבלת attributes וגודל מצליחות, אבל קריאת תוכן מתחילה hydration; אם OneDrive רץ והרשת בריאה הקובץ נקרא, אחרת זה נכשל ב-0x8007016A או timeout
    check["בדיקת קיום / attributes / גודל"] --> ok1["מצליח"]
    open["קריאת תוכן"] --> hyd["Hydration מתחיל"]
    hyd --> cond{"OneDrive רץ והרשת בריאה?"}
    cond -->|כן| read["נקרא אחרי הורדה"]
    cond -->|לא| err["שגיאה כמו 0x8007016A או timeout"]

איור 9: בדיקת קיום יכולה להצליח והקריאה להיכשל. ההצלחה תלויה במצב OneDrive וברשת.

5.2. תהליך batch משרה הורדה של כל קובץ

Batch שקורא כל קובץ בתיקייה, חישוב hash, full-text search, או backup עצמאי שמכוון תחת OneDrive משרים hydration על כל קובץ שנגעו בו. בתיקייה של כמה GB העיבוד לא רק נעשה איטי באופן חריג; ההורדה גם לוחצת על הדיסק, ובמחשב עם מעט מקום פנוי זה מביא תקלה אחרת. הקיבולת ש-Files On-Demand חסך נעלמת בסריקה מלאה אחת.

עוד נקודה: אם אפליקציה עושה hydration בלי פעולה מפורשת של המשתמש, Windows לפעמים מציג toast ומציע למשתמש לחסום. אחרי חסימה האפליקציה ממשיכה להיכשל בהורדות (אפשר לשחרר ב-«Automatic file downloads» בהגדרות). זה אחד הגורמים ל-«הייבוא נכשל רק במחשב מסוים».⁴

flowchart TB
    accTitle: תהליך batch משרה הורדה של כל קובץ
    accDescr: Batch תחת OneDrive משרה hydration על כל קובץ שנגעו בו, גורם לעיכוב ולחץ דיסק, ואם toast מוצג והמשתמש חוסם ההורדות נכשלות גם בהמשך
    scan["Batch תחת OneDrive"] --> touch["Hydration לכל הקבצים שנגעו בהם"]
    touch --> cost["עיכוב ולחץ דיסק"]
    touch --> toast["לפעמים מוצג toast"]
    toast --> block{"המשתמש חסם?"}
    block -->|כן| fail["ההורדות נכשלות גם בהמשך"]
    block -->|לא| cont["ההורדה נמשכת"]

איור 10: Batch משרה hydration לכל הקבצים, ואם חוסמים ב-toast הכישלון נמשך.

5.3. קוד שלא מצפה ל-attributes מתנהג לא נכון

קוד שלא מכיר FILE_ATTRIBUTE_OFFLINE או RECALL_ON_DATA_ACCESS נשבר במקומות לא צפויים.

• השוואת attributes בשוויון מלא (attributes == FileAttributes.Archive וכדומה) גורמת ל-placeholder להיחשב «קובץ לא צפוי» ולהיות מודר או להיכשל
• כלי backup/sync מפרשים OFFLINE כ-«כבר פונה לטייפ» ומדלגים (או להפך, לא מדלגים ומושכים את כל הקבצים)
• בדיקת read-only או מניפולציה של archive bit שוברת את צירוף ה-attributes

flowchart TB
    accTitle: דפוסי כשל בקוד שלא מצפה ל-attributes
    accDescr: קוד שלא מכיר attributes של placeholder נכשל בהשוואת שוויון מלא, בפרשנות שגויה של OFFLINE שמדלגת או מושכת הכול, ובשבירה של צירוף attributes
    code["קוד שלא מצפה ל-attributes"] --> m1["השוואת שוויון מלא"]
    code --> m2["פרשנות שגויה של OFFLINE"]
    code --> m3["מניפולציית attributes שוברת צירוף"]
    m1 --> r1["הדרה או שגיאה כלא-צפוי"]
    m2 --> r2["דילוג או משיכה מלאה"]

איור 11: קוד שלא מכיר attributes מסוג OFFLINE או RECALL נכשל בהדרה, דילוג שגוי או שבירת attributes.

Microsoft כותבת במפורש ב-guidance למפתחי minifilter לא להנפיק קריאה/כתיבה פזיזה לקובץ עם RECALL_ON_DATA_ACCESS. זה מסמך ל-kernel drivers, אבל העיקרון «לגעת בתוכן של קובץ עם התכונה הזו = לשלם עלות שליפה» חל כמו שהוא גם על אפליקציות user-mode.¹⁰

5.4. אינטראקציה בין FileSystemWatcher לסנכרון

כשעוקבים אחרי תיקייה תחת OneDrive עם FileSystemWatcher, מגיעים לא רק אירועי המשתמש אלא גם אירועים מפעילות אפליקציית הסנכרון, בהיקף גדול. בכל סנכרון שינוי ממכשיר אחר, ובכל שינוי attribute או גודל ב-hydration/dehydration, יכול להגיע Changed. אם העיצוב הוא לקלוט שינוי ולכתוב את תוצאת הייבוא חזרה לאותה תיקייה, מקבלים לולאה של כתיבה → upload → עדכון attributes → אירוע חוזר — «סערת שינויים». דילול אירועים ואימות תוכן אמיתי מכוסים ב-«מדריך מעשי ל-FileSystemWatcher», ותחת OneDrive הצורך הזה חד יותר.

flowchart TB
    accTitle: לולאת התראות מתוך מעקב וכתיבה חזרה
    accDescr: אפליקציית מעקב שכותבת תוצאת ייבוא חזרה לאותה תיקייה אחרי Changed גורמת ל-upload ולעדכון attributes מצד אפליקציית הסנכרון, ואלה מייצרים שוב אירוע — לולאת סערת שינויים
    ev["Changed"] --> proc["אפליקציית המעקב קולטת"]
    proc --> write["כתיבה חזרה לאותה תיקייה"]
    write --> up["אפליקציית הסנכרון מעלה"]
    up --> attr["Attributes או גודל מתעדכנים"]
    attr --> ev
    sync["סנכרון שינוי ממכשיר אחר"] -.-> ev

איור 12: כתיבת תוצאת ייבוא חזרה לאותה תיקייה יוצרת לולאה עם פעילות אפליקציית הסנכרון.

5.5. קונפליקט סנכרון בזמן exclusive lock, וקבצי «copy»

כל עוד האפליקציה העסקית פותחת קובץ ב-exclusive lock, אפליקציית הסנכרון לא יכולה להעלות או לעדכן אותו. אפליקציה שמחזיקה lock לאורך זמן (Access .accdb, קובץ נתונים בפורמט עצמאי, log) שיושבת תחת OneDrive הופכת שגיאות סנכרון לנורמה. ולהפך: עריכה של אותו קובץ בכמה מחשבים גורמת לאפליקציית הסנכרון לנסות לשמור את שתי הגרסאות, ונוצרים כפילויות עם שם מחשב או «copy». ייבוא שמניח «תיקייה אחת, קובץ אחד» נשבר על הכפילות הזו. יסודות עיצוב lock מכוסים ב-«ידע בסיסי על exclusive locking בהעברת קבצים».

flowchart TB
    accTitle: בעיות סנכרון מ-exclusive lock ומעריכה בכמה מחשבים
    accDescr: כל עוד האפליקציה מחזיקה exclusive lock אפליקציית הסנכרון לא יכולה לעדכן ושגיאות סנכרון הופכות לנורמה; עריכה של אותו קובץ בכמה מחשבים מייצרת conflict copies ששוברות הנחת קובץ אחד לתיקייה
    lock["האפליקציה פותחת ב-exclusive lock"] --> nosync["אי אפשר לסנכרן; שגיאות סנכרון כנורמה"]
    multi["עריכה של אותו קובץ בכמה מחשבים"] --> conflict["נוצרים conflict copies"]
    conflict --> dup["כפילויות עם שם מחשב או copy"]
    dup --> bad["הנחת קובץ אחד לתיקייה נשברת"]

איור 13: Exclusive lock הופך שגיאות סנכרון לנורמה; עריכה בכמה מחשבים מייצרת conflict copies ששוברות ייבוא.

5.6. Antivirus ו-search indexer משרים hydration

לא רק האפליקציה העסקית קוראת תוכן. Full scan של antivirus ו-search indexer גם הם משרים hydration אם הם נוגעים בתוכן של placeholder. Microsoft Defender וכדומה מדלגים על קבצים עם RECALL_ON_DATA_ACCESS בסריקת on-demand, אבל זו התנהגות של המוצר; אין ערובה שכל מוצר אבטחה ינהג באותה זהירות. אם «בכל סריקת לילה הרשת והדיסק נתקעים» או «קבצים שהפכנו ל-online-only כולם הפכו לתוכן מקומי בבוקר», חשדו בקו הזה.¹⁴

flowchart TB
    accTitle: Hydration שמושרה על ידי מוצר אבטחה או search indexer
    accDescr: כש-full scan או search indexer נוגעים בתוכן של placeholder, מוצר שמתחשב ב-RECALL מדלג, ומוצר שלא מתחשב עושה hydration לכל הקבצים וגורם לעומס לילה או להפיכה לתוכן מקומי בבוקר
    av["Full scan או search indexer"] --> care{"מתחשב ב-RECALL?"}
    care -->|מוצר שמתחשב| skip["מדלג על placeholders"]
    care -->|מוצר שלא מתחשב| hyd["נוגע בתוכן ועושה hydration"]
    hyd --> sym1["בלילה רוחב פס ודיסק נתקעים"]
    hyd --> sym2["בבוקר כל הקבצים הפכו לתוכן מקומי"]

איור 14: סריקה שלא מתחשבת ב-attributes משרה hydration לכל הקבצים, ונראית כעומס לילה או כהפיכה לתוכן מקומי בבוקר.

6. תגובת פיתוח האפליקציה — לכבד placeholders

מדיניות הבסיס למפתח היא לטפל ב-placeholder לא כ-«קובץ שבור» אלא כ-«קובץ שיש לו עלות שליפה».

• בזמן enumerate מזהים לפי attributes ולא פותחים בפזיזות. בסריקת תיקייה קודם בודקים attributes (הזיהוי בפרק 4) אם הקובץ online-only, ופותחים רק קבצים שצריך את התוכן שלהם. לעיבודים ש«בלי זה לא קריטי» — איסוף לוגים, חישוב hash, יצירת preview — תנו אפשרות לדלג על placeholders.

// .NET FileAttributes does not define these values; define them numerically
const FileAttributes RecallOnDataAccess = (FileAttributes)0x00400000;
const FileAttributes RecallOnOpen       = (FileAttributes)0x00040000;

static bool IsCloudPlaceholder(FileAttributes attributes) =>
    (attributes & (RecallOnDataAccess | RecallOnOpen | FileAttributes.Offline)) != 0;

foreach (var file in new DirectoryInfo(watchFolder).EnumerateFiles("*.csv"))
{
    if (IsCloudPlaceholder(file.Attributes))
    {
        log.Warn($"{file.Name} はオンライン専用のため今回は処理をスキップします");
        continue;
    }
    Import(file.FullName);
}

flowchart TB
    accTitle: זיהוי לפי attributes בזמן enumerate ואז פתיחה
    accDescr: בסריקת תיקייה קודם בודקים attributes ב-enumerate; אם זה placeholder מדלגים וכותבים אזהרה ללוג, ורק קבצים אחרים נכנסים לייבוא, כדי להימנע מ-hydration פזיז
    enum["בודקים attributes ב-enumerate"] --> ph{"Placeholder?"}
    ph -->|כן| skip["מדלגים וכותבים אזהרה"]
    ph -->|לא| imp["מריצים ייבוא"]
    skip -.-> note["פותחים רק קבצים שצריך את התוכן שלהם"]

איור 15: בזמן enumerate מזהים לפי attributes, ועל placeholders מדלגים בלי לפתוח כדי להימנע מ-hydration פזיז.

• שימו לב ש-FILE_FLAG_OPEN_NO_RECALL אינו ערובה ל-«לא להוריד». ציון הדגל הזה ב-CreateFile מצהיר על כוונה «לא לכתוב את הנתונים שהתקבלו חזרה לאחסון המקומי, להשאיר אותם בצד המרוחק». אבל זה דגל שלא מקבע מקומית נתונים שכבר התקבלו; אם קוראים תוכן, העברת הנתונים עצמה כן קורית. אם רוצים להימנע מרוחב פס ומ-latency עצמם, הסתפקו ב-attributes, גודל ו-timestamps — אל תבקשו read access (פתחו עם access 0, או השתמשו ב-metadata מתוצאת enumerate).⁹

flowchart TB
    accTitle: האפקט והגבול של FILE_FLAG_OPEN_NO_RECALL
    accDescr: FILE_FLAG_OPEN_NO_RECALL הוא דגל שלא מקבע מקומית נתונים שהתקבלו; קריאת תוכן עדיין מעבירה נתונים, ולכן אם רוצים להימנע מהעברה הכי בטוח להסתפק ב-metadata כמו attributes
    flag["פתיחה עם דגל NO_RECALL"] --> read["קוראים תוכן"]
    read --> transfer["העברת נתונים כן קורית"]
    transfer --> nolocal["לא מקובע מקומית"]
    meta["מסתפקים ב-metadata"] --> safe["אין העברה; הכי בטוח"]

איור 16: FILE_FLAG_OPEN_NO_RECALL רק מונע קיבוע מקומי; כדי להימנע מהעברה עצמה הסתפקו ב-metadata.

• הוסיפו ל-error message «זה תחת OneDrive». בכישלון קריאה, בדיקה אם נתיב היעד יושב תחת %OneDrive% והכנסתו להודעה מקצרת מאוד את זמן המיון בשטח וב-helpdesk. אם מזהים שגיאת cloud-file כמו 0x8007016A, האידיאל הוא להנחות «בדקו את מצב OneDrive».
• אל תשימו את תיקיית הנתונים של האפליקציה תחת OneDrive. בסביבת KFM גם «Documents» יושב תחת OneDrive. הגדרות, database וקבצי עבודה של האפליקציה שימו ב-%ProgramData% או %LocalAppData%, ואל תבחרו Desktop או Documents כברירת מחדל לתיקיית שמירה או ייבוא. איפה לשים מה מסודר ב-«How to Choose Where a Windows App Stores Local Data».
• החליטו מראש מה קורה אם המשתמש בחר נתיב תחת OneDrive. באפליקציה שנותנת למשתמש לבחור תיקיית שמירה, הכניסו למפרט מראש: אזהרה כשהנתיב שנבחר יושב תחת OneDrive (תחת משתני הסביבה OneDrive/OneDriveCommercial), או סירוב רק ל-lock file ול-DB.

7. תגובת צד ה-IT —‏ pin ומדיניות

מצד IT, הגישה המציאותית אינה «לכבות לגמרי את Files On-Demand» אלא להבטיח תוכן מקומי רק במקומות שהעסק צריך.

• עשו pin לתיקיות שהאפליקציה העסקית קוראת. מלחיצה ימנית ב-Explorer בחרו «Always keep on this device», או הריצו בסקריפט kitting attrib +p -u <folder> /s /d (מציינים גם -u באותו זמן כדי לעבור ל-pin גם אם מעורבבים קבצים שכבר online-only). לקובץ pinned מובטח תוכן מקומי, והוא גם מחוץ להמרה האוטומטית ל-online-only שיידון בהמשך.⁷²
• **KFM ו-Files On-Demand הם «מגדירים במכוון», לא «הבנו שזה דלוק». **המדיניות העיקרית (Group Policy / Intune) כדלקמן.¹¹¹

• הכירו את תנועת Storage Sense. ל-Storage Sense יש תכונה שמחזירה אוטומטית ל-online-only קבצי ענן שלא נפתחו מספר ימים, ואפשר להגדיר את מספר הימים במדיניות (ConfigStorageSenseCloudContentDehydrationThreshold). ברירת המחדל היא 0 (לא מחזיר אוטומטית), אבל אם המשתמש הדליק את זה במסך ההגדרות, או שהארגון הגדיר למחשבים עם מעט קיבולת, «קובץ שנפתח בשבוע שעבר חזר לאייקון ענן» הוא התנהגות תקינה. קבצים pinned מחוץ להיקף, כך שגם כאן «pin לתיקיות עסקיות» עובד.¹²²

flowchart TB
    accTitle: פיצול ההמרה האוטומטית ל-online-only של Storage Sense
    accDescr: בשחרור אוטומטי של Storage Sense קובץ pinned מחוץ להיקף והתוכן המקומי נשמר, וקובץ בלי pin שלא נפתח מספר ימים חוזר ל-online-only
    ss["שחרור אוטומטי של Storage Sense"] --> pin{"Pinned?"}
    pin -->|כן| stay["מחוץ להיקף; התוכן נשמר"]
    pin -->|לא| old{"לא נפתח מספר ימים?"}
    old -->|כן| dehyd["חוזר ל-online-only"]
    old -->|לא| keep["התוכן נשמר"]
    ss -.-> def["ברירת מחדל 0 לא מחזירה אוטומטית"]

איור 17: Storage Sense מחזיר ל-online-only קבצים שלא נפתחו מספר ימים, אבל pin מחוץ להיקף.

• כיבוי Files On-Demand רק אחרי שמעריכים את ההשפעה. FilesOnDemandEnabled ב-Disabled מחזיר לסנכרון הורדה מלאה בסגנון הישן, אבל צריכת דיסק ועומס רוחב הפס בסנכרון הראשון קופצים. Microsoft ממליצה להשאיר Enabled, וכיבוי צריך להיחשב צעד מוגבל אחרי שאישרתם ש-«כמות הנתונים של המשתמשים קטנה» ו-«יש מקום בדיסק».¹¹²
• הכניסו לנוהל התמיכה. שלבו את נוהל המיון בפרק הבא בתבנית הפנייה «קובץ בשולחן העבודה לא נפתח», כדי שאיכות הטיפול תישאר אחידה גם כשהאחראי מתחלף.

8. נוהל מיון — כשאומרים לכם «הקובץ לא נפתח»

כשמקבלים פנייה, בודקים מלמעלה למטה.

ה-workaround הזמני הוא לחיצה ימנית על תיקיית היעד ובחירת «Always keep on this device» (או attrib +p /s /d). התוכן המקומי מתמלא והעסק יכול לחזור לעבוד. אחר כך מחליטים אם הסיבה היסודית היא בצד האפליקציה (פרק 6) או בצד IT (פרק 7), ועוברים לטיפול קבוע.

flowchart TB
    accTitle: מה-workaround הזמני לטיפול הקבוע
    accDescr: Workaround זמני של Always keep on this device ממלא תוכן מקומי ומאפשר לחזור לעבודה, ואז מחליטים אם הסיבה היסודית בצד האפליקציה או בצד IT ועוברים לטיפול קבוע
    aid["Pin זמני כ-workaround"] --> restore["התוכן המקומי מתמלא"]
    restore --> resume["חוזרים לעבודה"]
    resume --> judge{"הסיבה היסודית?"}
    judge -->|צד האפליקציה| dev["לטיפול בפרק 6"]
    judge -->|צד IT| ops["לטיפול בפרק 7"]

איור 18: Workaround זמני הוא pin שממלא תוכן מקומי ומחזיר את העבודה; טיפול קבוע מחליט אם זה צד אפליקציה או צד IT.

אם אחרי כל זה «הנתיב אינו תחת OneDrive» ו-«זה גם לא placeholder», ממשיכים לגורמים קלאסיים אחרים כמו shared folder ואורך נתיב. «Pitfalls of Network Drives and UNC Paths» ו-«MAX_PATH and Windows Path/Filename Pitfalls» הם המפה להמשך.

9. סיכום

• בגלל KFM, התוכן האמיתי של Desktop, Documents ו-Pictures יכול לשבת תחת C:\Users\<name>\OneDrive\. אפליקציה שמניחה נתיב קבוע נשברת כאן. הצעד הראשון הוא לפתור עם known folder API.
• Files On-Demand דלוק כברירת מחדל, ו-placeholders בלי תוכן מקומי קיימים כדבר שבשגרה. Placeholder הוא reparse point של Cloud Files API (cldflt.sys), ופתיחה עושה hydration אוטומטית.
• אפשר לזהות מצב לפי file attributes (OFFLINE / RECALL_ON_DATA_ACCESS / PINNED / UNPINNED); ב-attrib הם נראים כ-O, P, U. בדיקת attributes בלבד אינה גורמת להורדה.
• תאונות באפליקציה עסקית מופיעות ככישלון hydration ב-offline, הורדה מלאה מתהליך batch, קוד שלא מצפה ל-attributes, אינטראקציה בין FileSystemWatcher לסנכרון, קונפליקט בין exclusive lock לסנכרון, ו-hydration שמושרה על ידי מוצר אבטחה.
• בצד האפליקציה הבסיס הוא «לזהות לפי attributes ולא לפתוח בפזיזות», «לא לשים תיקיית נתונים תחת OneDrive», ו-«בשגיאה לומר שזה תחת OneDrive».
• בצד IT בונים מצב מכוון עם «pin לתיקיות עסקיות» ועם «שליטת מדיניות על KFM, Files On-Demand ו-Storage Sense».
• המיון מתקדם מכנית בסדר נתיב → attrib → מצב OneDrive → רשת → מקום פנוי → תיעוד.

בפעם הבאה שמקבלים פנייה «הקובץ נראה אבל לא נפתח», שאלו קודם כך.

האם לקובץ הזה באמת יש תוכן בדיסק המקומי, או שרק המראה של הענן יושב שם?

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

• The Depths of Windows I/O (Part 5) — NTFS Internals: Understanding the File System Through the MFT
• מדריך מעשי ל-FileSystemWatcher — התמודדות עם פספוסים וכפילויות
• Pitfalls of Network Drives and UNC Paths — Working With File Servers (Shared Folders) From a Business Application
• ידע בסיסי על exclusive locking בהעברת קבצים — file lock ו-claim אטומי
• How to Choose Where a Windows App Stores Local Data — A Decision Table for SQLite / JSON / Registry / Access
• MAX_PATH and Windows Path/Filename Pitfalls — the 260-Character Limit, Reserved Names, Trailing Dots, and Case Sensitivity

תחומי ייעוץ קשורים

KomuraSoft LLC מטפלת בחקירת כשלי אפליקציות עסקיות שמערבים OneDrive ו-cloud storage — «ייבוא שעבד כבר אינו עובד אחרי החלפת מחשב», «קובץ לא נפתח רק במחשב מסוים» — עיצוב ותיקון של עיבוד קבצים ו-watch שמניחים placeholders, וסקירות עיצוב מיקום שמירה בסביבת KFM / Files On-Demand. להתחיל מבידוד הסימפטום זה בסדר — אנא צרו קשר.

• Windows Custom Software Development
• חקירת תקלות ואיתור גורמים
• ייעוץ טכני וסקירת תכנון
• יצירת קשר

קישורי עיון

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

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

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

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

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

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

שאלות נפוצות

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

אפליקציה עסקית אומרת "הקובץ לא נמצא" ואינה קוראת CSV שהנחתי בשולחן העבודה. למה?

במקרים רבים תיקיית Desktop עצמה הועברה אל C:\Users\<user>\OneDrive\Desktop על ידי Known Folder Move (KFM) של OneDrive, או שהקובץ הוא placeholder במצב online-only. אפליקציה שמניחה נתיב קבוע כמו C:\Users\<user>\Desktop לא מוצאת את הקובץ אחרי ההעברה. גם כשהנתיב נכון, קובץ online-only עלול להיכשל בפתיחה כש-OneDrive נעצר או הרשת לא בריאה. קודם בדקו אם נתיב היעד יושב תחת OneDrive, ובדקו ב-attrib אם U (online-only) דלוק. כ-workaround זמני אפשר להבטיח תוכן מקומי עם "Always keep on this device" בתפריט לחיצה ימנית.

אפשר לדעת מתוך תוכנית אם קובץ הוא online-only?

כן. Placeholder במצב online-only נושא attributes כמו FILE_ATTRIBUTE_OFFLINE ו-FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS (0x00400000), כך שאפשר לקרוא את המצב מ-file attributes בלי להוריד את התוכן. Get attributes או enumerate של תיקייה לא גורמים ל-hydration (הורדה). ב-.NET חלק מהערכים אינם מוגדרים על FileAttributes, ולכן ממירים ל-int ובודקים ב-bitwise. אם באמת צריך לפתוח בלי לקרוא את התוכן, זמין גם FILE_FLAG_OPEN_NO_RECALL של CreateFile.

כיבוי Files On-Demand פותר את הבעיה?

התייחסו לכיבוי כמוצא אחרון. השבתה מורידה מקומית כל קובץ בהיקף הסנכרון, כך שקיבולת הדיסק ועומס הרשת של הסנכרון הראשון גדלים, ו-Microsoft גם ממליצה להשאיר את התכונה דלוקה. בפועל גמיש יותר לעשות pin רק לתיקיות שהאפליקציה העסקית קוראת ("Always keep on this device"). ביסודו, התיקון האמין הוא לתכנן מחדש כך שתיקיית הנתונים ותיקיית הייבוא של האפליקציה לא יישבו תחת ניהול OneDrive.

הגדרתי "Always keep on this device", אבל חלק מהקבצים חוזרים בסוף לאייקון ענן. למה?

קודם בדקו ב-attrib שלקובץ באמת יש pin (תכונת P). קובץ pinned נמצא מחוץ להמרה האוטומטית ל-online-only של Storage Sense, אבל קובץ שהוא רק "locally available" כי מישהו פתח אותו, בלי pin, יכול לחזור ל-online-only אחרי פרק זמן לפי הגדרות Storage Sense ומדיניות. פעולת "Free up space" של המשתמש עצמו, ומדיניות שהופכת קבצי team site ל-online-only (DehydrateSyncedTeamSites), גם מחזירות את אייקון הענן. לתיקיות שחייבות להישאר מקומיות לעסק, הפעילו pin בהיקף תיקייה.

פרופיל הכותב

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

Go Komura

מנהל KomuraSoft LLC

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