קבצי OneDrive לפי דרישה ויישומים עסקיים — ההנחות שממלאי מקום שוברים וכיצד להתמודד

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

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

במילים אחרות, ההנחה הסמויה של יישום עסקי ש”הקובץ נמצא בדיסק המקומי” הוחלפה, בלי שאף אחד החליט על כך, בהנחה ש”הקובץ בענן, ומקומית יש רק את המראה”. מיועד לאנשי IT בארגונים קטנים ובינוניים ולמפתחי יישומי Windows, המאמר מסדר ממקורות ראשוניים של Microsoft Learn איך ממלאי מקום עובדים, איך לשפוט מצב מתכונות קובץ, המלכודות הטיפוסיות שיישום עסקי דורך בהן, מה צד הפיתוח וצד ה־IT יכולים לעשות, ונוהל מיון כשאומרים לכם “הקובץ לא נפתח”.

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

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

1. השורה התחתונה קודם

• שולחן העבודה, מסמכים ותמונות אולי הועברו תחת C:\Users\<שם>\OneDrive\ על ידי KFM. זה נוטה להידלק בהקמה הראשונית של מחשב חדש, וארגון יכול גם להחיל זאת בכמות גדולה במדיניות. יישום שמניח נתיב קבוע נשבר כאן.¹
• קבצים לפי דרישה דולקים כברירת מחדל באפליקציית הסנכרון הנוכחית. קבצים שנוצרו במכשיר אחר או באינטרנט מופיעים כממלאי מקום “מקוון בלבד” בלי תוכן מקומי.²³
• הזהות האמיתית של ממלא מקום היא נקודת reparse שמנוהלת על ידי Cloud Files API (המיניפילטר cldflt.sys). הוא נראה כקובץ רגיל לסייר ולממשקי הקבצים, ופתיחתו מורידה (מהדרה) אוטומטית.⁴
• אפשר לשפוט מצב מתכונות קובץ. FILE_ATTRIBUTE_OFFLINE, RECALL_ON_DATA_ACCESS, PINNED, UNPINNED וכדומה הם הסימנים, ופקודת attrib מציגה אותם כאותיות O, P ו־U. בדיקת תכונות בלבד אינה גורמת להורדה.⁵⁶⁷
• תאונות טיפוסיות ביישום עסקי הן שילוב של “לא נפתח”, “איטי”, “תכונות נשפטו לא נכון”, “סערת אירועי צפייה” ו”קונפליקט עם סנכרון”. לא מקוון או כש-OneDrive נעצר, הידרציה נכשלת, ותהליך אצווה משרה הורדה של כל קובץ.⁴⁸
• תגובת צד היישום היא “לכבד ממלאי מקום”. הבסיס הוא לשפוט מתכונות בזמן מנייה ולא לפתוח בפזיזות, להשתמש ב־FILE_FLAG_OPEN_NO_RECALL אם צריך, ולא לשים את תיקיית הנתונים תחת OneDrive.⁹¹⁰
• תגובת צד ה־IT היא “להפעיל עם הצמדות” ו”שליטה במדיניות”. הבטיחו תוכן אמיתי לתיקיות עסקיות עם “שמור תמיד במכשיר זה”, והגדירו KFM וקבצים לפי דרישה במכוון עם Group Policy / Intune. אל תשכחו ש-Storage Sense יכול גם “להחזיר קבצים שאינם בשימוש למקוון בלבד”.¹¹¹²

במשפט אחד: “קובץ שנראה בסייר” ו”קובץ שיש לו תוכן אמיתי בדיסק המקומי” כבר אינם אותו דבר.

2. מה קורה — KFM וקבצים לפי דרישה

2.1. שולחן העבודה אולי כבר אינו C:\Users\<שם>\Desktop

לאפליקציית הסנכרון של OneDrive יש תכונה בשם Known Folder Move (KFM). במסך ההגדרות היא מוצגת כ”גיבוי”, “גבה תיקיות חשובות” וכדומה; כשהיא דולקת, שולחן העבודה, מסמכים ותמונות האמיתיים מועברים (מנותבים מחדש) תחת תיקיית OneDrive.¹

בהקמה הראשונית (OOBE) של מחשב חדש, כניסה עם חשבון Microsoft או חשבון עבודה מציגה בהרחבה גיבוי תיקיות כהצעת ברירת מחדל, והמשך כפי שהוא מדליק אותה. ארגון יכול גם להחיל זאת בכמות גדולה בלי לשאול את המשתמש דבר, עם המדיניות “העבר בשקט תיקיות ידועות של Windows ל-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 נדלק בלי שאף אחד שם לב, בין בהצעת ברירת המחדל בהקמה הראשונית ובין במדיניות ההחלה השקטה של הארגון.

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

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

איור 3: אחרי KFM, יישום שמשתמש בממשקי תיקיות ידועות ממשיך לעבוד, אבל יישום שמקודד נתיב קבוע נשבר כאן.

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

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

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

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

stateDiagram-v2
    accTitle: שלושת מצבי קבצים לפי דרישה והמעברים
    accDescr: קובץ מקוון בלבד הופך לזמין מקומית בפתיחה, אבל שחרור מקום או Storage Sense יכולים להחזיר אותו למקוון בלבד, ורק קובץ מוצמד נמצא מחוץ לשחרור אוטומטי
    s1: מקוון בלבד (סימן ענן)
    s2: זמין מקומית
    s3: מוצמד (שמור תמיד במכשיר זה)
    s1 --> s2: פתיחה (הידרציה)
    s2 --> s1: שחרור מקום
    s2 --> s1: Storage Sense
    s1 --> s3: שמור תמיד במכשיר זה
    s2 --> s3: שמור תמיד במכשיר זה
    s3 --> s2: ביטול הצמדה

איור 4: שלושת מצבי קבצים לפי דרישה. “זמין מקומית” יכול לחזור אוטומטית למקוון בלבד; הצמדה מחוץ לזה.

3. הזהות האמיתית של ממלא מקום — Cloud Files API ונקודות reparse

קבצים לפי דרישה מיושמים מעל מנגנון מערכת שהוצג ב-Windows 10 גרסה 1709, Cloud Files API. יחידת העבודה בצד מערכת הקבצים היא מיניפילטר בשם cldflt.sys (שם השירות CldFlt, “Windows Cloud Files Filter Driver”), ו-OneDrive הוא אחד מ”ספקי הסנכרון” שמשתמשים בממשק הזה.⁴⁷

ממלא מקום מבחינה טכנית הוא נקודת reparse. במערכת הקבצים קיימים רק מטא־נתונים כמו שם, גודל וחותמות זמן (כ־1KB); אין נתוני תוכן. כשהיישום פותח את הקובץ וקורא, המיניפילטר מזהה את הבקשה, מורה לספק הסנכרון להעביר את הנתונים, ממתין לסיום ההורדה, ואז הקריאה ממשיכה. השליפה הזו נקראת הידרציה; השלכת התוכן המקומי וחזרה לממלא מקום נקראת דה־הידרציה.⁴

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

איור 5: קריאת ממלא מקום ממשיכה אחרי שהמיניפילטר גורם לספק הסנכרון לשלוף את הנתונים.

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

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

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

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

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

איור 7: ממלא מקום מציג את הגודל המקורי כ”גודל” בעוד “גודל בדיסק” כמעט 0.

4. תכונות הקובץ מספרות את המצב

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

פקודת attrib בשורת הפקודה יכולה להציג ולהגדיר אלה כאות אחת. O היא תכונת לא מקוון, P מוצמד, U לא מוצמד.⁶ ההתאמה למצב קבצים לפי דרישה של OneDrive מסודרת בתיעוד מיקרוסופט כך.⁷

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

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

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

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

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  # שמור תמיד במכשיר זה
        Unpinned           = ($value -band 0x00100000) -ne 0  # מקוון בלבד
    }
}

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

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

5. מלכודות שיישום עסקי דורך בהן

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

5.1. פתיחה מתחילה הורדה אוטומטית — “לא נפתח” לא מקוון

פתיחת קובץ מקוון בלבד מתחילה הידרציה במקום. מקוון, עם קובץ קטן, זה כל כך מהיר שלא שמים לב, אבל כש-OneDrive נעצר, מנותק או מושהה, כשהרשת אינה בריאה, או כשהקובץ גדול, זה הופך ל”קובץ שקיים אבל לא נפתח”. השגיאה יכולה לחזור כקוד ממשפחת קבצי ענן כמו ERROR_CLOUD_FILE_PROVIDER_NOT_RUNNING (0x8007016A, “The cloud file provider is not running”), או להיראות כפסק זמן בצד היישום.⁸

מלכוד נוסף הוא שבדיקת קיום שקולה ל־File.Exists(), וקבלת תכונות או גודל, מצליחות. מקבלים דפוס שגיאה שאינטואיציית הדיסק המקומי אינה מסבירה: “בדיקת הקיום עברה, אבל הקריאה נכשלה”.

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

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

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

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

גם, אם יישום גורם להידרציה בלי פעולת משתמש מפורשת, Windows יכול להציג toast ולתת למשתמש בחירה לחסום. אחרי חסימה היישום ממשיך להיכשל בהורדות (אפשר להסיר עם “הורדות קבצים אוטומטיות” בהגדרות). זה אחד הגורמים ל”הייבוא נכשל רק במחשב מסוים”.⁴

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

איור 10: אצווה משרה הידרציה של כל קובץ, ואם נחסמה ב-toast הכישלונות ממשיכים לאחר מכן.

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

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

• תכונות נבדקות לשוויון מדויק (attributes == FileAttributes.Archive וכדומה), ולכן ממלא מקום מודר או מטופל כשגיאה כ”קובץ בלתי צפוי”
• החלטת הדרה בכלי גיבוי או סנכרון מפרשת את תכונת OFFLINE כ”כבר הועלה לקלטת” ומדלגת (או, להפך, שולפת כל קובץ שהיה צריך להדיר)
• בדיקת לקריאה בלבד או פעולת סיבית ארכיון שוברת את שילוב התכונות

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

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

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

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

צפו בתיקייה תחת OneDrive עם FileSystemWatcher ואתם מקבלים לא רק פעולות משתמש אלא גם מספר גדול של אירועים מפעילות אפליקציית הסנכרון. בכל פעם ששינוי במכשיר אחר מסונכרן, ובכל פעם שהידרציה או דה־הידרציה משנות תכונות או גודל, אירוע Changed יכול להידלק. יתר על כן, עיצוב שכותב את תוצאת הצפייה והייבוא חזרה לאותה תיקייה הופך ל”סערת התראות שינוי” בלולאה של כתיבה ← העלאה ← עדכון תכונות ← אירוע נוסף. דילול אירועים ועיצוב בדיקת תוכן אמיתי מכוסים ב־”מדריך מעשי ל-FileSystemWatcher”, אבל תחת OneDrive הצורך גבוה יותר בדרגה.

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

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

5.5. קונפליקטי סנכרון בזמן נעילה בלעדית, וקבצי “עותק”

בזמן שיישום עסקי פותח קובץ בנעילה בלעדית, אפליקציית הסנכרון אינה יכולה להעלות או לעדכן את הקובץ. הנחת יישום שמחזיק נעילה ארוכה (Access .accdb, קובץ נתונים בפורמט ביתי, קובץ יומן וכדומה) תחת OneDrive הופכת שגיאות סנכרון למצב הרגיל. ולהפך, כשאותו קובץ נערך בכמה מחשבים, אפליקציית הסנכרון מנסה לשמור את שתי המהדורות ומייצרת קובץ כפול עם שם מחשב או עותק קונפליקט כמו “— עותק”. ייבוא שמניח “תיקייה אחת, קובץ אחד” מתנהג לא נכון על הכפיל הזה. יסודות עיצוב נעילה ב־”ידע בסיסי על בקרת הרשאות בלעדיות בהעברת קבצים”.

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

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

5.6. אנטי־וירוס ומאנדקס החיפוש משרים הידרציה

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

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

איור 14: סריקה שאינה מכבדת את התכונה משרה הידרציה של כל קובץ, ומופיעה כעומס לילי או התממשות בוקר.

6. תגובת פיתוח היישום — כבדו ממלאי מקום

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

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

// הגדירו כמספרים ערכים ש-FileAttributes ב-.NET אינו מגדיר
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: מסלול שיפוט מתכונות בזמן מנייה ואז פתיחה
    accDescr: בסריקת תיקייה תחילה ודאו תכונות במנייה; אם ממלא מקום, דלגו והשאירו יומן אזהרה, והריצו ייבוא רק על הקבצים האחרים, כדי להימנע מהידרציה פזיזה
    enum["ודאו תכונות במנייה"] --> ph{"ממלא מקום?"}
    ph -->|כן| skip["דלגו והשאירו יומן אזהרה"]
    ph -->|לא| imp["הריצו את הייבוא"]
    skip -.-> note["מדיניות לפתוח רק קבצים שצריכים את תוכנם"]

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

• שימו לב ש-FILE_FLAG_OPEN_NO_RECALL אינו הבטחה של “אל תורידו”. ציון הדגל הזה ב-CreateFile יכול לציין כוונה ש”נתונים שהושגו יישארו בצד המרוחק ולא ייכתבו חזרה לאחסון המקומי”. אבל זה דגל רק שלא להפוך נתונים שהושגו לתושבים מקומית; אם קוראים את התוכן, העברת הנתונים עצמה עדיין מתרחשת. אם רוצים להימנע מרוחב הפס וההשהיה עצמם, סיימו עם תכונות, גודל וחותמות זמן בלבד — אל תבקשו גישת קריאה (פתחו עם הרשאות גישה 0, השתמשו במטא־נתונים מתוצאת המנייה). זה הבטוח ביותר.⁹

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

איור 16: FILE_FLAG_OPEN_NO_RECALL רק מונע הפיכה לתושב מקומית; אם רוצים להימנע מההעברה עצמה, סיימו עם מטא־נתונים בלבד.

• שימו “זה תחת OneDrive” בהודעת השגיאה. בכשל קריאה, עצם האישור אם נתיב היעד נמצא תחת %OneDrive% והכללתו בהודעה מקטינים מאוד את זמן המיון לשטח ולשולחן העזרה. אם מזהים שגיאה ממשפחת קבצי ענן כמו 0x8007016A, האידיאל הוא לומר למשתמש “אנא בדקו את מצב OneDrive”.
• אל תשימו את תיקיית הנתונים של היישום תחת OneDrive. בסביבת KFM, גם “מסמכים” נמצאים תחת OneDrive. שימו הגדרות, מסד נתונים וקבצי עבודה ב־%ProgramData% או %LocalAppData%, ואל תבחרו בשולחן העבודה או במסמכים כמיקום שמירה ברירת מחדל או כתיקיית ייבוא ברירת מחדל. איך מחליטים מה לשים איפה מסוכם ב־”How to Choose Where a Windows App Stores Local Data”.
• החליטו על ההתנהגות כשהמשתמש בוחר מיקום תחת OneDrive. ליישום שנותן למשתמש לבחור מיקום שמירה, כללו במפרט מראש החלטת עיצוב כמו אזהרה כשהנתיב שנבחר תחת OneDrive (תחת נתיב משתני הסביבה OneDrive / OneDriveCommercial), או סירוב רק להצבת קובץ נעילה או מסד נתונים.

7. תגובת צד ה־IT — שלטו בהצמדות ובמדיניות

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

• הצמידו את התיקיות שיישום עסקי קורא. בחרו “שמור תמיד במכשיר זה” מתפריט לחיצה ימנית בסייר, או הריצו attrib +p -u <folder> /s /d מסקריפט דימוי (מציינים -u באותו זמן כדי שתערובת קבצים שכבר מקוונים בלבד תוחלף באמינות למוצמד). לקובץ מוצמד מובטח תוכן אמיתי מקומית והוא גם מחוץ להמרה האוטומטית למקוון בלבד שיידון בהמשך.⁷²
• הגדירו KFM וקבצים לפי דרישה “במכוון”, לא “גילינו שדולק כששמנו לב”. המדיניות העיקרית (Group Policy / Intune) כדלקמן.¹¹¹

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

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

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

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

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

כשמקבלים את הייעוץ, ודאו מלמעלה למטה.

הפתרון הזמני הוא ללחוץ ימנית על תיקיית היעד ולבחור “שמור תמיד במכשיר זה” (או attrib +p /s /d). זה מסדר את התוכן האמיתי מקומית והעסק יכול להתחדש. מעל זה, החליטו אם הסיבה המהותית בצד היישום (פרק 6) או בצד ה־IT (פרק 7) כתגובה קבועה.

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

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

אם וידאתם עד כאן ו”הנתיב אינו תחת OneDrive” וגם “זה אינו ממלא מקום”, ממשיכים לגורמים קבועים אחרים כמו תיקייה משותפת או אורך נתיב. “Pitfalls of Network Drives and UNC Paths” ו־”MAX_PATH and Windows Path/Filename Pitfalls” הם המפה להמשך.

9. סיכום

• KFM אולי העביר את שולחן העבודה, מסמכים ותמונות האמיתיים תחת C:\Users\<שם>\OneDrive\. יישום שמניח נתיב קבוע נשבר כאן. פתרון עם ממשקי תיקיות ידועות הוא הצעד הראשון.
• קבצים לפי דרישה דולקים כברירת מחדל, וממלאי מקום בלי תוכן מקומי קיימים כדבר מובן מאליו. ממלא מקום הוא נקודת reparse של Cloud Files API (cldflt.sys), ופתיחתו מהדרה אוטומטית.
• אפשר לשפוט מצב מתכונות קובץ (OFFLINE / RECALL_ON_DATA_ACCESS / PINNED / UNPINNED) והוא מופיע כ־O, P ו־U ב-attrib. בדיקת תכונות בלבד אינה גורמת להורדה.
• תאונות יישומים עסקיים מופיעות ככישלון הידרציה לא מקוון, הורדה מלאה מתהליך אצווה, קוד שאינו מצפה לתכונות, אינטראקציה בין FileSystemWatcher לסנכרון, קונפליקט בין נעילה בלעדית לסנכרון, והידרציה שמושרית על ידי מוצר אבטחה.
• בצד היישום, הבסיס הוא “שפטו מתכונות ואל תפתחו בפזיזות”, “אל תשימו את תיקיית הנתונים תחת OneDrive”, ו”אמרו שזה תחת OneDrive כשאתם מדווחים על שגיאה”.
• בצד ה־IT, יוצרים את המצב המכוון עם “הצמדת תיקיות עסקיות” ו”שליטת מדיניות ב-KFM, קבצים לפי דרישה ו-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
• ידע בסיסי על בקרת הרשאות בלעדיות בהעברת קבצים — נעילת קבצים ושיטות עבודה מומלצות ל-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 ואחסון ענן — “ייבוא שעבד כבר אינו עובד אחרי החלפת מחשב”, “קובץ לא נפתח רק במחשב מסוים” — עיצוב ותיקון של עיבוד קבצים וצפייה שמניחים ממלאי מקום, וסקירות עיצוב מיקום שמירה בסביבת KFM / קבצים לפי דרישה. להתחיל מבידוד הסימפטום זה בסדר — אנא צרו קשר.

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

קישורי עיון

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

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

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

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

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

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

שאלות נפוצות

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

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

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

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

כן. ממלא מקום מקוון בלבד נושא תכונות כמו FILE_ATTRIBUTE_OFFLINE ו-FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS (0x00400000), כך שאפשר לשפוט את המצב מתכונות הקובץ בלי להוריד את התוכן. קבלת תכונות או מנייה של תיקייה אינה גורמת להידרציה (הורדה). ב-.NET חלק מהערכים אינם מוגדרים על FileAttributes, ולכן ממירים למספר שלם ובודקים בפעולות bitwise. אם באמת צריך לפתוח בלי לקרוא את התוכן, זמין גם אמצעי כמו FILE_FLAG_OPEN_NO_RECALL של CreateFile.

האם כיבוי קבצים לפי דרישה פותר את הבעיה?

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

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

תחילה ודאו בפקודת attrib שלקובץ באמת יש הצמדה (תכונת P). קובץ מוצמד נמצא מחוץ להמרה האוטומטית למקוון בלבד של Storage Sense, אבל קובץ שהוא רק "זמין מקומית" כי מישהו פתח אותו, בלי הצמדה, יכול לחזור למקוון בלבד אחרי פרק זמן לפי הגדרות Storage Sense ומדיניות. פעולת "שחרור מקום" של המשתמש עצמו, ומדיניות שהופכת קבצי אתרי צוות למקוונים בלבד (DehydrateSyncedTeamSites), גם מחזירות את אייקון הענן. לתיקיות שחייבות להישאר מקומיות לעסק, הפעילו בהצמדה בהיקף תיקייה.

פרופיל הכותב

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

Go Komura

מנהל KomuraSoft LLC

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