One of the primary functions of the Links dialog box is to allow the user to repair broken links. This happens whenever the source of the linked data, for example a file, moves independently of the compound document. For example, if I create a link to the file C:\DATA\OLE\NEWFOR95.XLS and store it in the file C:\DATA\BOOK\CHAP20.DOC, I will break the link if I move the source file to C:\OLEDATA\NEWFOR95.XLS or otherwise rename it. In other words, the moniker that is serialized in the compound document for this link contains the original path. That path becomes invalid when I move or rename the source document. Attempting to activate the linked object in the compound document will now fail because C:\DATA\OLE\NEWFOR95.XLS no longer exists.
This does not happen, however, when the relative path between the compound document and the link source remains the same. For example, the relative path between the document C:\DATA\BOOK\CHAP20.DOC and the linked file C:\DATA\OLE\NEWFOR95.XLS is the path ..\OLE\NEWFOR95.XLS. Thus, we could move the entire C:\DATA directory into C:\OLEDATA, preserving the entire directory structure, and not break any links. We might also move the entire tree to another drive altogether. In any case, the links stay intact.
OLE accomplishes this by maintaining two monikers for a linked object: one has an absolute pathname for the file portion of the link (if it exists), and another contains a relative pathname in the file portion. This is why IMoniker has the member functions RelativePathTo and CommonPrefixWith, as we saw in Chapter 9. Having both relative and absolute references to a source file maintains connections in many circumstances.
However, a link source might move independently of the compound document, in which case the link is broken. Under current operating systems, the user must manually repair these links through the Links dialog box. That is, the user must search for the new location of the file. When the user finds it, the code in the Links dialog will create a new moniker and store it in the linked object with IOleLink::SetSourceMoniker.
Microsoft plans to provide much more automatic link tracking, as shown in Figure 20-5 on the following page. This will relieve the user from such a tedious chore. Link tracking will require that the system know when any file moves, what compound documents have links to that file, and where the monikers for those links are stored in the compound document itself. Windows NT already has a file system that knows when files move, so that problem is solved. The work that remains is to keep an index of which documents contain links to what other sources. Then, when the sources change, the system can automatically create a new moniker and write it over the old one in the compound document. This does require that the (outdated) moniker be accessible in the compound document file itself so that the system doesn't have to launch an application to have it open the file. This is another great reason to use a compound file for an application's storage needs: the system could easily browse through all the elements in a compound file looking for the right moniker stream. It could then update the moniker automatically and efficiently without ever having to load the file itself or run the application that created it.
Figure 20-5.
How automatic link tracking would work.