Or is vmware using the Library folder instead of the USERS\testuser\Library folder?
My bet would actually be on /tmp, not /Library. As I said, I don't know if this is true, but I suspect it is.
It is a know fact that Host to Guest (H2G) Drag and Drop (DnD) Transfers do first write to a Temp File Location within the Guest and because of this it can be a problem if enough free disk space is not available due to first having to write to a Temp File Location within the Guest first however I believe Guest to Host (G2H) is a different story...
From the tests I've preformed it looks like a DnD from G2H does not first write to a Temp File Location as it does when doing H2G and does indeed write directly to the target destination...
Using two different utilities that monitor low level filesystem activity as well as monitoring the read write activity of the physical disks at the hardware level as well as free/used space values monitored during the transfers and base on the results I received/observed I'm convinced that G2H DnD is directly written to the Target Destination.
To put the tests in perspective I used 2 FireWire External Drives, one containing the Leopard OS and Fusion 2.0 Virtual Machine running Windows XP and a 1 GB Test File and the second FireWire Drive as the destination for the DnD. This enabled me to watch the Read/Write LED on both drives. I booted my MBP from the FireWire Drive containing Leopard and Fusion with Virtual Machine with the second FireWire Drive attached as the DnD Destination.
The results of the software base monitoring supported the hardware based monitoring in that there were no changes in the free/used space values of either the Host's System Volume or the Guest's System Volume only the DnD Destination second FireWire drive nor where there any files created at the filesystem level on the Host's System Volume of within the Guest at the start of the transfer however the only change it the state of the filesystem was an entry made with the direct path to the second FireWire drive and during the entire transfer of the 1 GB Test File the Read/Write LED on the Host's System Volume stayed Blue, which is the Read Color for this drives LED and the Read/Write LED on the Second FireWire Drive, the DnD Destination, it stayed Red which is the Write Color for this drives LED.
I'm not saying that based upon my tests/observations that this is absolutely a fact as it's know for H2G but it sure seems conclusive that G2H transfers are handled differently however for my two cents I think the failure is coming down to something else.
I totally agree with Eric in that using VMware Shared Folders or a Network Share is much better when trying to move large amounts of files or folders in either direction via the Drag & Drop feature. For small amounts and or just for ease of use DnD is a nice feature however for high volume transfers networking in the better choice to avoid possible issues surrounding DnD.
