I copied a directory hierarchy from host to guest via the "Shared Folders" feature. Once done, I closed explorer on the WinXP 32 bit guest, and attempted to delete the directory structure on the Win7 64bit host (rd /s/q dirname). I received multiple errors to the effect that "the process cannot access the file because it is being used by another process."
Shutting down the VM allowed me to complete the cleanup, but I don't believe this should be necessary. Anyone else experience this? Is there a solution?
It's nothing..sometime when u'r copying through share, the session isn't terminated immediately after the copying is completed..so when u tried to delete the directory, there was another process using it..
It's one of the normal glitches of windows :smileygrin:
The attempt to delete the directory structure was made quite some time after the copy; 5-10 minutes at least. I find it hard to believe this is normal Windows behavior; I'd think it would cause all sorts of mayhem in a network environment.
Thanks for your thoughts.
I came looking for an answer to the same sort of problem except with version 7.
While I am not certain of all the details it appears that once a file is opened by an application in the virtual machine the lock persists so long as that application is open. Time is *NOT* a factor, I have seen locks persist for days.
What's really nasty is that when the file was opened by Windows itself this still applies--but note that Windows never closes. The lock persists until the VM is shut down/rebooted.
I can confirm that this is *not* a normal Windows problem but is something that is caused by VMWare not letting the guest OS 'release' the files. This should be an easy bug fix from VMWare. While we wait for that, has anyone come up with a workaround that doesn't involve pausing or shutting down the guest?
I am running Windows 8 x64 host and Windows 7 x86 guest.
Some more experimenting has convinced me that the file lock is released by the termination of the *LAST* program to access it.
This means that you can release any lock by opening it with something you can then close--this will free up the file even if the original lock was due to Windows. Note that what you open it with need not be able to understand it--I used the file viewer in Total Commander as it can open a large file without reading it all into memory and won't puke on binary data.
I confirm this problem too ... Windows sometime takes a long time to release locks, but it finally does.
This is actually a SF problem.
Even in old versions of VMWare Player (4.0.1), this error exists (Host: Win7Pro/Guest: WinXPPro SP3).
Has anyone heard about a bug fix?
In Workstation 12.5, the problem persists.
A workaround is to use non-buffered copy mode.
In Win7+ guests, xcopy /j can be used.
In XP, copywobuf utility can copy a single file. To copy a directory tree, a simple CMD script (with for /r) can be used.