גרסת שחרור של rsyncrypto

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

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

המשך הפוסט הוא מחשביסטי למדי. ראו הוזהרתם.

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

המשפט שעלה בדעתי הוא משפט שאין לי מושג מי אמר אותו במקור:
“Sometimes it’s time to shoot the engineer and ship the damn product”

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

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

טיפה הסבר. ככל שיש למשתנה יותר מקום (נמדד בביטים) לשמור מספרים, הוא מסוגל להתמודד עם מספרים יותר גדולים (הפשטה פרועה. אני מבקש מכל הקטנוניים מבין קוראי לא לעשות בי לינץ’ במפגש הקרוב). בפרט, משתנה רגיל של 32 ביט, אם הוא מכיל ביט אחד לצורך סימן, מסוגל להגיע עד מספרים שסופרים 2GB, ואם הוא לא מכיל סימן מסוגל להגיע למספרים של 4GB. ליותר מזה אין לו מקום.

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

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

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

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

או כך חשבתי.

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

אופס

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

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

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

בתקווה שלא נצטרך גם להוציא גרסה 1.03 בשבוע הקרוב,

שחר