Strange file locking problem

[Gary Feldman]

I was testing installations today, and ran into a strange file locking problem.

I'd build the installation kit on the host machine in my directory, copy it over to the VMware host shared folder on the host side, and then switch windows (since the kit building takes place under the build account, while the testing takes place under the QA account; this was all with Remote Desktop, so I had two connections to the build/test machine). From the QA Account, I'd work on a virtual machine, and I could access the setup file directly from the \\.host tree and do the install. Typically I'd let it go so far and stop it, since I'm testing various ways to implement installation options.

Now here's the catch: I'll go back to the first window, rebuild the kit, and try to copy it over to the VMware host shared folder. At this point, I get a file locked message that prevents me from overwriting the previous kit, deleting the previous kit, etc. This is even though I've shut down the test installation on the virtual machine, but I left the virtual machine running and the user logged in.

If I shut down the virtual machine, then I can go back to the host machine and delete the installation kits that I didn't need anymore. But it's a nuisance to have to restart the machine every time I want to do an install. I can also fake it by renaming the setup.exe before copying it to the shared folder, but that's just a smaller nuisance.

Is this a known problem? Or is it something in my configuration that I've missed?

Many thanks,

Gary

[Nephi]

Question 1, what OS are you using for the host? I'm thinking Win2003 as by
what I
understand what you said, is that you can be on the host's console & Remote
Desktop (RD)
at the time. Or you're using XP with 2 individual accounts where you kill
the console,
when in RD then kill RD when going back to the console. *Console could be
another RD
session.

Taking my assumptions from above (either one). That you have 2 users logged
in at the
same time. And you are trying to modify/delete/write to the files that are
been used by
the other user. If that is the case, then you already found the problem.
Windows
unlike a POSIX system (I read your next post) can not handle file
modification/deletion
while a user is logged in and has it open. This is from the file locking
protection inWinodws.
The only way to fix this (with out rebooting) is to make sure you close all
programs in the
other user and log out. As *should* (who knows with windows ~_~) release the
file locks
on the files.

As a side note, under XP (not too sure about 2003) in the task manager,
there's a tab called
"Users" and in there you can kill the other user. Only if your account is an
administrator.

Also the file locking system under Windows, doesnt care if an administrator
is trying to
modify the files that a lesser user has opened (in a read/write state). This
is ment to help less
knowledgible (being highly kind here) users, from screwing up the system.

-- Nephi

Post by Gary Feldman
I was testing installations today, and ran into a strange file locking problem.
I'd build the installation kit on the host machine in my directory, copy
it over to the VMware host shared folder on the host side, and then switch
windows (since the kit building takes place under the build account, while
the testing takes place under the QA account; this was all with Remote
Desktop, so I had two connections to the build/test machine). From the QA
Account, I'd work on a virtual machine, and I could access the setup file
directly from the \\.host tree and do the install. Typically I'd let it
go so far and stop it, since I'm testing various ways to implement
installation options.
Now here's the catch: I'll go back to the first window, rebuild the kit,
and try to copy it over to the VMware host shared folder. At this point,
I get a file locked message that prevents me from overwriting the previous
kit, deleting the previous kit, etc. This is even though I've shut down
the test installation on the virtual machine, but I left the virtual
machine running and the user logged in.
If I shut down the virtual machine, then I can go back to the host machine
and delete the installation kits that I didn't need anymore. But it's a
nuisance to have to restart the machine every time I want to do an
install. I can also fake it by renaming the setup.exe before copying it
to the shared folder, but that's just a smaller nuisance.
Is this a known problem? Or is it something in my configuration that I've missed?
Many thanks,
Gary

[Gary Feldman]

Post by Nephi
Question 1, what OS are you using for the host? I'm thinking Win2003 as by
what I

The host is 2003. The virtual machine is XP Pro (though eventually I'll also be testing 2000 and 2003 on virtuals).

The machine on my desktop is an XP laptop that can't support VMware. So I use remote desktop for two connections to the 2003 server. One of those sessions is for the build account and the second for the test account. I hope this is clear enough.

Post by Nephi
Taking my assumptions from above (either one). That you have 2 users logged
in at the
same time. And you are trying to modify/delete/write to the files that are
been used by
the other user. If that is the case, then you already found the problem.
Windows
unlike a POSIX system (I read your next post) can not handle file
modification/deletion
while a user is logged in and has it open. This is from the file locking

Except that I can't figure out what has it open. The file is an installation kit, specifically an InstallShield setup.exe which wraps the .msi generated by InstallShield. My expectation is that when I've finished the installation, this file should be closed - so that I ought to be able to delete it. So the question is why is this being held open? I suppose I could install a tool that tracks file handles to find out.

Gary

[Nephi]

Ummm, I wouldnt know what file is been held open, as I only use the 1 RDP
connection on my set up. It could be a left over file-lock that windows
forgets to remove. Or that it'll remove after a reboot/log off.

Have you tried doing the modification & such under the one account?

As you are finding out Windows can do weird things when it wants to, and the
best way is to log off and/or reboot the PC. Oh and it becomes weirder when
RDP is used and multiple users.

-- Nephi

Post by Gary Feldman

Post by Nephi
Question 1, what OS are you using for the host? I'm thinking Win2003 as
by what I

The host is 2003. The virtual machine is XP Pro (though eventually I'll
also be testing 2000 and 2003 on virtuals).
The machine on my desktop is an XP laptop that can't support VMware. So I
use remote desktop for two connections to the 2003 server. One of those
sessions is for the build account and the second for the test account. I
hope this is clear enough.

Post by Nephi
Taking my assumptions from above (either one). That you have 2 users
logged in at the
same time. And you are trying to modify/delete/write to the files that
are been used by
the other user. If that is the case, then you already found the problem.
Windows
unlike a POSIX system (I read your next post) can not handle file
modification/deletion
while a user is logged in and has it open. This is from the file locking

Except that I can't figure out what has it open. The file is an
installation kit, specifically an InstallShield setup.exe which wraps the
.msi generated by InstallShield. My expectation is that when I've
finished the installation, this file should be closed - so that I ought to
be able to delete it. So the question is why is this being held open? I
suppose I could install a tool that tracks file handles to find out.
Gary

[Slawomir Piotrowski]

Hello, Gary!
You wrote on Mon, 24 Jan 2005 22:29:08 -0500:

??>> Taking my assumptions from above (either one). That you have 2 users
??>> logged in at the same time. And you are trying to modify/delete/write
??>> to the files that are been used by the other user. If that is the
??>> case, then you already found the problem. Windows unlike a POSIX
??>> system (I read your next post) can not handle file
??>> modification/deletion while a user is logged in and has it open. This
??>> is from the file locking

GF> Except that I can't figure out what has it open. The file is an
GF> installation kit, specifically an InstallShield setup.exe which wraps
GF> the .msi generated by InstallShield. My expectation is that when I've
GF> finished the installation, this file should be closed - so that I ought
GF> to be able to delete it. So the question is why is this being held
GF> open? I suppose I could install a tool that tracks file handles to
GF> find out.

sysinternals.com has a great tool to find out which file is opened and by
whom.

I remember I've had similar problems with an earlier version of VMware and
worked around that by deleting old files from the guest. I haven't tried to
find the source of problem and if it were Windows/VMware related.

Slawomir Piotrowski