פתרון מערכות קבצים ושינוי מבנה

ניסוי sparse מתחיל ב־CREATE_NEW עם גישה לכתיבה, כדי שלא ידרוס קובץ קיים. לאחר פתיחה מוצלחת שולחים FSCTL_SET_SPARSE, ורק אם הוא מצליח ממשיכים לשינוי הגודל. הכותרת winioctl.h מספקת את קוד הבקרה.

הקטע הבא מצטרף לתוכנית שמחזיקה handle חדש בשם file. כל כשל עוצר את הניסוי ומדווח; הפונקציה win_error היא פונקציית זריקה ששומרת GetLastError כפי שנלמד בפרקים הקודמים:

DWORD returned = 0;
if (!DeviceIoControl(file, FSCTL_SET_SPARSE, nullptr, 0,
                     nullptr, 0, &returned, nullptr))
    win_error("FSCTL_SET_SPARSE");

LARGE_INTEGER end{};
end.QuadPart = 16 * 1024 * 1024;
if (!SetFilePointerEx(file, end, nullptr, FILE_BEGIN) ||
    !SetEndOfFile(file))
    win_error("set sparse length");

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

חוזה העתקה מפורש

כלי שמעתיק רק את הזרם הראשי צריך לומר זאת. כלי שמבטיח שימור מלא יותר צריך למנות streams, הרשאות, timestamps וקישורים רלוונטיים, ולדווח כאשר יעד אינו תומך בתכונה. שימור hard links דורש טבלת זהויות כדי שלא ליצור שני עותקים עצמאיים של אותו תוכן.

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

משמעות היומן

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

השוואת NTFS ו־ReFS צריכה לצרף גרסת מערכת ותוצאת בדיקת תכונה. שם המערכת לבדו אינו תחליף לניסוי או לבדיקת תוצאת API.