How Windows 2000 Tracks Files Using Object IDs

Microsoft Windows 2000 introduced an architecture within NTFS that tracks files even when they are renamed or moved across different volumes and domain network shares. This article explains how Windows 2000 utilizes 16-byte Object Identifiers (OIDs) in coordination with the Distributed Link Tracking (DLT) service to maintain persistent file references across volume boundaries, ensuring that shortcuts and linked objects remain functional when their targets move.

The Role of Object Identifiers in NTFS

Windows 2000 introduced an updated version of the NTFS file system (NTFS 3.0, often called NTFS 5.0) that implemented native support for Object Identifiers. An Object ID is a 128-bit (16-byte) Globally Unique Identifier (GUID) assigned to a file or directory.

Unlike traditional file paths or File Reference Numbers (which are tied to specific Master File Table records on a single volume), an Object ID is stored directly as an NTFS attribute ($OBJECT_ID). This attribute contains:

  • Unique Object ID: The current identifier for the file on the current volume.
  • Birth Volume ID: The volume on which the file first received an Object ID.
  • Birth Object ID: The original Object ID assigned to the file upon creation.
  • Birth Domain ID: The network domain in which the file was originally created.

The Cross-Volume Move Mechanism

Within a single NTFS volume, moving a file is simply a directory entry update; the file's MFT record and Object ID remain untouched. However, moving a file across volumes requires a physical copy-and-delete operation, which creates a new file record on the destination volume.

Windows 2000 handles this cross-volume transition through the following steps:

  1. Preservation of Birth Attributes: When a file with an existing Object ID is moved to another NTFS volume, the file system transfers the original Birth Volume ID, Birth Object ID, and Birth Domain ID to the destination file's $OBJECT_ID attribute.
  2. Assignment of a New Object ID: A new Unique Object ID is generated on the destination volume, but the permanent historical link is preserved through the immutable Birth IDs.
  3. Notification to the Link Tracking Service: The Windows shell or moving application notifies the local Distributed Link Tracking service that a file relocation has occurred across volume boundaries.

The maintenance of these references across volumes relies on two core services:

  • Distributed Link Tracking Client (TrkWks): Runs on all Windows 2000 workstations and servers. It monitors volume activity, notices when files with Object IDs are moved across volumes, and logs the change.
  • Distributed Link Tracking Server (TrkSvr): Runs on Active Directory domain controllers. It maintains a centralized mapping database of moved files throughout the enterprise.

When a cross-volume move occurs within a domain environment, the local DLT Client contacts the DLT Server. The client registers a mapping that associates the file’s Birth ID with its new volume and current Object ID.

When a user or application attempts to access a moved file via a shortcut (.lnk file) or an Object Linking and Embedding (OLE) reference:

  1. Initial Path Check: The system first tries the last known absolute path. Because the file moved to another volume, this check fails.
  2. Local Volume Search: The system checks the local machine's DLT Client cache to see if the file moved to another local volume.
  3. Domain Query: If the target is not found locally, the DLT Client queries the DLT Server in Active Directory using the file's Birth ID.
  4. Path Resolution: The DLT Server provides the current computer, volume, and new Object ID. The client connects to that volume, requests the file path matching the Object ID, and resolves the link.
  5. Link Update: Once resolved, Windows updates the shortcut file with the new path to avoid network queries on subsequent accesses.