VMware Communities
Derek_G
Contributor
Contributor

Workstation 8 install fails Error 1320 - specified path is too long

The installion process for Workstation 8 fails with:

        Error 1320.  The specified path is too long C:\Users\Public\Documents\Shared Virtual Machines.

The install is clearly trying to confirm the existence of the "Shared Virtual Machines" folder, but if any

part of this path is an NTFS Directory Junction then the install fails.  In my case, the Documents directory

is an NTFS Join to another complete volume for my Public folders.   The error 1320 occurs even if the

"Shared Virtual Machines" folder already exists.

Since the "Shared Virtual Machines" folder can be created using standard Windows commands (i.e. a CMD file)

it would be helpful NOT to have to remove the junction just to install Workstation * because a lot of other

processes and applications have to be manually stopped to remove and restore this NTFS Junction.

As yet, I have no knowledge of any problems the NTFS Junction might cause when using the Shared Virtual

Machines functionality in Workstation 8.  This would make it quite a show stopper as opposed to just an

installation irritation.

0 Kudos
4 Replies
continuum
Immortal
Immortal

nteresting
does the installer ask for a path tothe shared VMs ?
if not may be it would help
to write a file like this named datastores.xml yourself and put it into


<ConfigRoot>
  <LocalDatastores>
    <_length>1</_length>
    <_type>hostd.host.LocalDatastoreEntry[]</_type>
    <e id="0">
      <_type>hostd.host.LocalDatastoreEntry</_type>
      <id>1</id>
      <name>standard</name>
      <path>C:\Users\Public\Documents\Shared Virtual Machines</path>
    </e>
  </LocalDatastores>
  <NasVolumes>
    <_length>0</_length>
    <_type>hostd.host.NasDatastoreEntry[]</_type>
  </NasVolumes>
</ConfigRoot>

and put it into C:\ProgramData\VMware\hostd
Probably you should then use a different path ...


________________________________________________
Do you need support with a VMFS recovery problem ? - send a message via skype "sanbarrow"
I do not support Workstation 16 at this time ...

0 Kudos
Derek_G
Contributor
Contributor

Thanks for the heads-up on the datastores file.  Modifying or creating the file prior to installing Workstation 8 does not fully work around the problem.  You have to do a custom install and change the file path to a non-junction and non-networking drive.  Post install, the path can then be changed by modifying the datastores file as you suggest - even reverting to the original VMware installation default.

I'm just a bit concerned that customers have to modify drive configuration settings in order to install Workstation 8.  The way I chose to set up my system's drive and interconnections works perfectly well for Microsoft Windows and a load of applications from leading software houses, so I don't feel I'm living on the fringe of technology with unrealistic expectations!  I'm just a bit surprised that beta testing did not uncover this problem (maybe I should volunteer my energies for Workstation 9).

Anyway, I have it working and thanks for the contribution to the role of the datastores file.

0 Kudos
jbudreau
VMware Employee
VMware Employee

Hi Derek,

I glad that you were able to get your Workstation installation up and running properly.  I've tried to reproduce your install failure by duplicating your windows junction directory setup and have been unable to run into any install errors.  If you're still interesting in helping us figure out what happened during your initial installation could you attempt to reproduce the install error you were receiving earlier and gather up all the vm*.log files from inside your %temp% directory and attach them to this thread?

Thanks,

Joel

0 Kudos
Derek_G
Contributor
Contributor

Joel,

I have performed a reinstall for Workstation 8 and attached the logs as you requested. I wonder if some screenshots of my directory structure would also help? In essence there are two nested junctions:

mklink /J "D:\Users" "M:\Users"

mklink /J "C:\Users\Public\Documents" "D:\Users\Public\Documents"

Unusual I know, but it helps with switching to offline mode when the server on drive M: is unavailable. Windows gets a bit angry if "C:\Users\Public" goes temporarily missing and is re-joined to another drive, but it couldn't care less if "D:\Users" is re-joined to a local drive instead of a netwoked drive (and vice versa). I believe it is because "C:\Users\Public\Documents" is one of Windows 7's Libraries that it doesn't allow any modifying of the directory structure. It has to be done in safe mode to initially hook into drive 😧 where on it is then far easier to re-join "D:\Users" to whatever you like.

I hope this is some help for you to investigate further.

Derek Godsell

0 Kudos