Mac OSX 10.6.8 host.
Win XP guest.
I've used symlinks to directories extensively to keep my filesystem sane and to simplify sharing with guest OSes and via DropBox. This approach has worked quite well in the past.
However, after upgrading to Parallels 7, symlinks on the host Mac filesystem are *no longer* recognized by the Windows guest as regular directories, but instead as *Windows shortcuts*. This completely breaks path handling in Windows for any path that includes a symlinked directory from the host filesystem:
* Shortcuts that include a symlink in the path fail to open anything, and fail silently without any error message. These used to work just fine in Paralles 6.
* Typing a path into Explorer that includes a symlink generates an error, stating "Windows cannot find '[path you typed in]'. Check the spelling and try again, or try searching for the item by clicking the Start button and then clicking Search." This applies to both mapped drives, and fully-qualified paths (starting with "\\psf\..."). This also used to work just fine in Parallels 6.
Note that this is with proper symbolic links created in the host Mac filesystem, using the "ln -s [path to source] [path to where to place the symlink]" Bash syntax. This is *not* about Mac aliases, created by the Finder.
Confusingly, the Finder shows symlinks as aliases when viewed in the Info window. Running "ls -a" in Bash shows symlinks as symlinks, and aliases as regular files. Both symlinks and aliases are recognized by the Windows guest as Windows shortcuts, suggesting that Parallels is translating both without distinction. I suspect that changes to Parallels 7 to support Mac aliases have introduced this regression.
For reference, I also run VMware on an Ubuntu 10.04 host with a Windows XP guest, and in that setup, symlinked directories in the host filesystem are recognized in the Windows guest as regular directories, and shortcuts and Explorer paths work just as if the symlink were a regular directory. ***This is the expected behavior for Parallels as well, and _was_ the actual behavior in Parallels 6.***
I would appreciate any further information about this regression, and particularly any news of when it might be fixed.
Thank you,
Last edited: Feb 19, 2012