Monday, January 10, 2011

VMware Workstation 7 in Windows 7: Error Moving File or Folder

I had just started using Windows XP SP3 as a guest in VMware Workstation 7.1 on a Windows 7 host.  It seemed that I was getting a certain error every time I tried to move files from one folder to another.  Both the target and source drives were on network drives, in the VMware sense:  they were local drives on that computer, but they were not part of the actual virtual machine (VM) as drive C was, so Workstation considered them network drives.  When I attempted to paste these files into a folder on that other drive, I got this error message:

Error Moving File or Folder

Cannot move [filename]: It is being used by another person or program.

Close any programs that might be using the file and try again.
These files were not in use anywhere, as far as I could tell.  I was using a utility called Unlocker.  When this kind of error would occur, Unlocker would pop up, provide relevant information, and offer to help.  In this case, Unlocker's message was, "No locking handle found."  This was not absolutely the last word on the subject, but I had found Unlocker to be pretty reliable.

This was happening every time I tried to move files.  It was not a problem with one particular troublesome file.  It happened with moving files, not with deleting them.  I was able to delete files, and copy files; I just couldn't move files.  I had done a global change of file properties so that none were read-only.  This inability to move files occurred on all network drives.

I did a search on this error.  Very few results turned up.  I posted a question on it in a VMware forum.  One of the results from the search led to a lot of instances where people were getting the same or a similar error message in non-VM contexts.  Some of the advice offered in those kinds of situations involved one-off solutions, where there was a particularly troublesome file.  Someone suggested trying to do this as administrator, but I was already running as administrator.

That last person remarked that the errors s/he was experiencing may have resulted from changing the host name on the computer.  This was not a newly created VM.  I had used it in Workstation for Linux, to run WinXP on an Ubuntu host on a separate computer.  When I brought it over to this computer and fired it up, Workstation asked whether I had copied or moved it.  I said I moved it.  So possibly what was happening was that Workstation remained confused about some aspect of the machine due to the fact that it was not a virgin WinXP creation.

To explore this possibility, I closed down this VM and started up another.  I didn't want to spend the time to create a whole new WinXP installation in a VM.  What I did instead was to choose a preexisting VM that had different origins.  So now I felt that I should clarify the genealogy of this thing.  This troublesome VM was not actually created in Workstation.  It was created by VMware Converter.  I had used Converter to convert a native WinXP installation into a VM that I then used in Workstation for Linux.

I did have another WinXP VM that I had created in Workstation for Linux -- installing Windows XP from scratch inside a virtual machine, that is, rather than installing it on a regular computer and then converting it.  So that was the one I tried using now.  The problem did not occur there.  These differences in origins may have explained the difference in behavior.  It may also have had something to do with the differences in size.  The converted native machine was twice the size of the born-in-virtual machine.  Its size itself may have been an issue, or there may have been a problem with some program that I had installed within that larger machine.

0 comments: