Word Uses UNC Path, Even with NoLongNetNames=Yes

ID: Q121808

The information in this article applies to:

Microsoft Word for Windows, versions 6.0, 6.0a, 6.0c

NOTE: This article does NOT apply to Microsoft Word for Windows NT, version 6.0, or to Word for Windows 95, version 7.0, running under Windows NT.

SYMPTOMS

Primary Symptom

If the NoLongNetNames setting is Yes in your WINWORD6.INI file, Word for Windows uses a universal naming convention (UNC) path instead of a logical drive letter when you create a link using either of the following methods:

Insert Object Command: From the Insert menu, choose Object, select the Create From File tab, and select the Link To File check box.
Edit Paste Special Command: From the Edit menu, choose Paste Special and select the Paste Link option.

For example, Word might insert the following sample LINK field (which incorrectly uses a UNC path):

   { LINK Word.Document.6 "\\\\SERVER\\NAME\\WINWORD\\FILE.DOC" "" \a \p }

By contrast, if NoLongNetNames=Yes, Word correctly uses a logical drive letter when you create a link using either of the following commands:

Insert File Command: From the Insert menu, choose File, and select the Link To File check box.
Insert Picture Command: From the Insert menu, choose Picture, and select the Link To File check box.

For example, Word might insert the following correct LINK field:

   { LINK Word.Document.6 "G:\\WINWORD\\FILE.DOC" "" \a \p }

Secondary Symptom

Under Novell 3.11, when Word incorrectly uses a UNC path, as described above, either of the following problems may occur:

Opening a Word 2.x document in Word 6.0:
In Word 6.0, if you open a Word 2.x document and update the links, Word 6.0 converts the drive letter to a UNC path or to a nonexistent, nonpersistent logical drive letter, and the following error occurs:
```
      Error: Cannot update links. <Application name> cannot find
      <filename>.
```
Inserting LINK Using UNC Path:
If Word 6.0 incorrectly creates a UNC link as described above, a general protection (GP) fault occurs in OLE2.DLL.

CAUSE

Word uses two different Windows application program interface (API) calls to perform the Insert Object and Edit Paste Special commands described above. Only one of the API calls responds to the NoLongNetNames setting, so the other API call causes Word to incorrectly use a UNC path in the LINK field.

STATUS

Microsoft has confirmed this to be a problem in the versions of Word listed above. We are researching this problem and will post new information here in the Microsoft Knowledge Base as it becomes available.

WORKAROUND

1. Insert or paste the object without creating a link. To omit the link,

   clear the Link To File check box in the Edit Paste Special or Insert
   Object dialog box before you choose OK to complete the operation.

2. Select and delete the object you inserted or pasted in step 1.

3. Insert or paste the same object again, but this time, select the Link To

   File check box before you choose OK. This time, Word successfully
   creates a LINK field using the correct drive letter.

REFERENCES

"Microsoft Word User's Guide," version 6.0. Document number WB51157-1093, pages 610-614; document number WB60460-0794, pages 638-642.

KBCategory: kbusage buglist 6.0 buglist6.0a buglist6.0c KBSubcategory: kbfield Additional reference words: 6.0 6.0a 6.0c winword APIs hang hung crash crashed locks locked frozen freezes crashing quit quits stopped word6 crashes bomb bombs bombed

Keywords          : kbfield 
Version           : 6.0 6.0a 6.0c
Platform          : WINDOWS

Last Reviewed: August 6, 1997