The "._" files erroneously created on the Host will not get deleted if the main file is trashed. The Guest does not see critical information (I noticed it, because some applications on the Host appeared as "UNIX executable" files on the Guest).Ģ. This, of course, creates loads of problems when using VMware's sharing.
It has the Extended Attribute "quarantine" because it was downloaded from the Internet, using Safari.īut the long listing for the same file, as seen on the Guest, does not show Extended Attributes (nor are there any "._" files): Here is the problem in the opposite direction: the listing for the VMware application on the Host shows Extended Attributes: _* file as containing the Extended Attributes that should attached to the file. HFS+, or the Host's Finder, does not recognise the. Next, having used the Finder in the Guest to copy the file over to the Host's desktop, I look at it on the Host:Īs you can see, the transferred file has no Extended Attributes, which are instead stored in a new "._" file in other words, the transfer was made as if the protocol used was SMB or NFS, even though both ends are MacOS with HFS+ formatted disk drives. You can see the in the long listing, indicating that the screenshot has Extended Attributes and then the xattr(1) command shows what type they are. If I take a screenshot in the Guest, then the resulting file has Extended Attributes. One of the issues is related to this thread:Įxtended Attributes are not handles correctly for shared folders, presumably because the sharing mechanism uses a non-Apple protocol (such as SMB or NFS). (The purpose is to have Rosetta to run older PowerPC applications.) This setup appears not to be fully supported with all features, but more of that elsewhere.
#RUNNING VMWARE ON MAC WITH OSMOJAVE PRO#
I am running MacOSX "Snow Leopard Server" 10.6.8 as a Guest on a Mac Pro (late 2013) with "Yosemite" 10.10.2 as the host. Hi, I have a related question, or indeed may have found a related bug:
0 kommentar(er)
