VMware Communities
RkHvc
Contributor
Contributor

Fusion 3.1.3 problem with Windows 8.3 short names and shared folders - bug report

Mac OS X 10.7.1 Lion

Fusion 3.1.3

VM: Windows XP SP3

Just did a test upgrade of one of our build systems from Mac OS X 10.6.8 and Fusion 2.0.8 to Mac OS X 10.7.1 and Fusion 3.1.3 and ran into a problem using shared folders where the Windows WDK build tools were unable to access the build directories that they had just created on a shared folder.

Here's a simple procedure for demonstrating the underlying issue.

Fusion 3.1.3 is generating 8.3 short names on shared folder volumes, but it's not mapping the 8.3 short names correctly to the underlying Mac folder.

Steps to Reproduce:

  1. In the VM Settings create a Shared Folder "SharedDir" that maps to a folder on the Mac host.
  2. In the Windows VM, open a Command Prompt and execute the following commands:

Map the shared directory to the w drive letter:

subset w: "\\vmware-host\Shared Folders\SharedDir"

Change to the w drive:

w:

List the shared directory contents:

dir

Create a test directory:

mkdir LongDirName

List the shared directory contents, adding the /X arg to have it also display the 8.3 short names:

dir /X

Example output with OS X 10.7.1 and Fusion 3.1.3:

09/02/2011  11:15 AM    <DIR>    LONG~565     LongDirName

Create a test sub-directory, first using the directory's full name:

mkdir LongDirName\LongSubDirTest1

Now create a 2nd test sub-directory, this time using the directory's 8.3 short name (as shown in the dir /X output):

mkdir LONG~565\LongSubDirTest2

Result:

Instead of mapping the short name to the correct directory, it has created a second directory based on the 8.3 short name.

Looking at the shared folder on the Mac host, the results are:

LONG~565/

LongSubDirTest2/

LongDirName/

LongSubDirTest1/

Expected behavior:

Both the directory's full name and 8.3 short name should resolve to the same directory on the shared folder on the Mac host.

LongDirName/

LongSubDirTest1/

LongSubDirTest2/

This issue does not occur with Fusion 2.0.8 on Mac OS X 10.6.8.  In fact with the same test it appears that Fusion 2.0.8 doesn't support 8.3 short names on shared folders as the "dir /X" output step above doesn't list any 8.3 short names.

Anyone else run into this?

Looking for a workaround.  Is there any way to disable 8.3 name support on shared folders in Fusion 3.1.3?

I found that there's a registry setting in Windows that can be used to disable 8.3 name support; I tried it but it only works for local file systems -- not for network shares.

Reply
0 Kudos
0 Replies