איך קיצור דרך ב-Windows מוצא קובץ שהעברתם? — המיקום של הקובץ והזהות שלו הם שני דברים שונים

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

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

למה אפשר למצוא קובץ שכבר אינו נמצא במקום שבו היה?

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

1. קודם כול בודקים את המיקום הקודם

נניח שהעברתם את ההצעה מ-C:\Work\Drafts\plan.txt אל C:\Work\Submit\plan.txt, באותו כרך NTFS.

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

flowchart TB
    accTitle: העברת ההצעה מפרידה בין הנתיב הישן לבין מקומה הנוכחי
    accDescr: בתיקיית טיוטות שקיצור הדרך זוכר אין יותר את ההצעה, ואותה הצעה עברה לתיקיית הגשה.
    L["קיצור הדרך"] --> O["טיוטות - כבר לא שם"]
    F["אותה הצעה"] --> N["הגשה - היא כאן"]

איור 1: מנגנון שהולך אחרי המיקום הישן בלבד היה מגיע כאן למבוי סתום.

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

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

אז על מה הוא נשען כשגם השם השתנה?

2. שימוש בתג שם שנשאר גם אחרי שינוי שם

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

מה שעוזר במצב כזה הוא מידע מזהה שנפרד מהמיקום ומהשם.

המנגנון של Windows שנקרא מעקב קישורים מבוזר (distributed link tracking) משתמש ב-Object ID שמצורף לקובץ או לתיקייה ב-NTFS. Object ID אינו מאפיין חובה; הוא מעין תג שם שמזהה את מה שרוצים לעקוב אחריו. בתוך אותו כרך מוכן גם אינדקס לחיפוש לפי Object ID.⁵

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

flowchart TB
    accTitle: מידע מזהה שנשאר אחרי העברה ושינוי שם באותו כרך
    accDescr: כשמידע המעקב נשמר, אותו תג שם הוא הרמז שמאפשר לעקוב אחרי ההצעה בטיוטות עד למסמך ההצעה בהגשה, אף שהשם והמיקום השתנו.
    A["plan.txt עם תג שם K"] -->|"העברה ושינוי שם"| B["proposal.txt עם תג שם K"]
    L["מידע המעקב בקיצור הדרך"] -.->|"חיפוש עם K כרמז"| B

איור 2: המיקום של קובץ יכול להשתנות בלי שהמידע המזהה שמשמש למעקב ישתנה יחד איתו.

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

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

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

3. כשהמזהה לא מוצא, מחפשים לפי מאפיינים

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

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

אפשר לסכם את המסלול עד כאן כך.

flowchart TB
    accTitle: הרמז עובר מהמיקום השמור למידע המעקב ואחר כך למאפיינים
    accDescr: אם היעד אינו במיקום השמור, מנסים את מידע המעקב הזמין, ואם גם זה לא מוצא את היעד, מנסים חיפוש לפי מאפיינים.
    P["בדיקת המיקום השמור"] -->|"לא נמצא"| I["שימוש במידע המעקב"]
    I -->|"לא זמין או לא נמצא"| S["חיפוש מועמדים שהמאפיינים שלהם מתאימים"]

איור 3: קווי המתאר של פתרון קישור רגיל. האם בכלל מתבצעים מעקב וחיפוש תלוי גם בהגדרות ובאופן הקריאה.

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

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

4. העתק עם אותו תוכן הוא אותו קובץ?

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

גם ה-Object ID אינו מועתק כמו שהוא בהעתקה רגילה. אילו היו באותו כרך שני קבצים עם אותו ID, תג השם כבר לא היה מאפשר להבדיל ביניהם. Microsoft מסבירה שהעתק אינו יורש את אותו Object ID כמו המקור.⁵

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

איור 4: לגרום לתוכן להיות זהה אינו אותו דבר כמו להעביר את הקובץ המקורי עצמו.

הנה עוד מקרה שמפתיע אנשים. אחרי שההצעה המקורית הועברה להגשה, מה יקרה אם שמים קובץ אחר עם אותו שם במקום שהתפנה, Drafts\plan.txt?

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

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

5. איך לעקוב אחרי אותו קובץ במחשב שלכם

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

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

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

בזמן הכתיבה אימתתי את ההתנהגות גם עם IShellLinkW::Resolve על NTFS מקומי ב-Windows Server 2025 (build 26100). אחרי העברה ושינוי שם התקבל הנתיב החדש, ובניסיון נפרד שבו הונח קובץ אחר במיקום המקורי התקבל הנתיב הישן. זו תצפית על ה-API בסביבה אחת, לא בדיקה דרך ממשק סייר הקבצים ב-Windows 11, וגם לא אימות של איזה מסלול חיפוש פנימי שימש. גם רשומת הבדיקה נשמרת.

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

6. למפתחים: קריאת נתיב לעומת חיפוש מחדש

גם כשאפליקציה עובדת עם .lnk, מפרידים בין קריאת המידע השמור לבין חיפוש אחרי יעד שהלך לאיבוד. קבלת הנתיב עם GetPath על IShellLink וניסיון לפתור את הקישור עם Resolve אינם אותה פעולה.⁷

flowchart TB
    accTitle: טוענים את קיצור הדרך ואחר כך פותרים את היעד
    accDescr: טוענים את הקישור עם IPersistFile, מנסים לפתור עם Resolve, ומוציאים את הנתיב שנפתר עם GetPath אחרי שמאמתים שהפעולה הצליחה.
    L["טעינת הקישור"] --> R["ניסיון לפתור עם Resolve"]
    R -->|"אימות ההצלחה"| G["קבלת הנתיב עם GetPath"]

איור 5: קריאת המחרוזת של המיקום המקורי אינה אותו דבר כמו לחפש את המיקום החדש.

בעיבוד אוטומטי גם ממשק המשתמש שמוצג כשלא נמצא דבר, משך החיפוש, השימוש במעקב והאם מידע הקישור מתעדכן — כל אלה הם החלטות תכנון. לדוגמה, SLR_NOSEARCH מדכא את החיפוש לפי מאפיינים, ו-SLR_NOTRACK מדכא את השימוש במעקב קישורים מבוזר. בוחרים את ה-flags לפי המטרה, ולא מתייחסים לכך ש”משהו נפתח” כאל הצלחה.²

שימו לב שה-Object ID שנועד למעקב וה-file ID שמתקבל מ-handle של קובץ אינם אותו פריט. השוואה של מזהי קבצים כוללת גם את הכרך. אין לערבב ביניהם רק מפני ששניהם נקראים ID; בודקים איזה מזהה ומאיזה API מדובר. אין צורך לכתוב Object ID מחדש ביד.⁸⁹

כמו כן, ה-.lnk שנדון כאן הוא קובץ של ה-shell. הוא שונה מקישור סימבולי שפועל בתוך פתרון הנתיבים של מערכת הקבצים, ולכן אי אפשר להעביר אליו כמו שהוא את התיאור הזה של החיפוש.¹⁰

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

ב-diagram, solid line מציינת relation שתמיד מתקיים ו-dashed line מציינת relation מותנה (התנאים מופיעים בהסבר של כל relation ב-detail page). הרשימה המלאה של ה-relations (סה”כ 5, כולל evidence ו-certainty) וההגדרות של ה-concepts המרכזיים נמצאות ב-detail page של ה-knowledge map (ביפנית). Data: JSON-LD / Turtle

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

• הסרה בטוחה של כונן USB ומטמון הכתיבה

מקורות

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

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

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

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

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

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

שאלות נפוצות

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

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

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

האם קיצור דרך משווה את תוכן הקבצים כדי למצוא את הקובץ המקורי?

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

אם שמים קובץ אחר עם אותו שם במקום המקורי, האם ייפתח הקובץ שהועבר?

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

האם המעקב מובטח אחרי העברה לכונן USB או למחשב אחר?

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

האם קיצור דרך וקישור סימבולי הם אותו דבר?

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

פרופיל הכותב

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

Go Komura

מנהל KomuraSoft LLC

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