ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <>
Subject Re: [Re: Windows Directory Locking]
Date Wed, 01 Aug 2001 17:42:08 GMT

----- Original Message -----
From: "Butch Clark" <>
To: <>
Sent: Wednesday, August 01, 2001 07:40
Subject: Re: [Re: Windows Directory Locking]

>I'd be interested in seeing if anyone has a good solution to this issue.
>have noticed that on Win2k the file locking can be a REAL problem.  There
>been times we've copied files into the deployment directory that one of the
>servers is using, and when the server restarts, the original locked version
>magically appears back where the new file used to be.  Unfortunately, I
>haven't seen any consistency with exactly how this happens, or even when...

>It's gotten to the point where we go to heroic lengths to _ensure_ that
>is deployed is exactly what we think is deployed.  I.e., shutting down the
>servers, deleting all the files, making sure they're _really_ not there,
>redeploying the files, restarting the servers, etc.

>Anyone else had these kinds of experiences (he asked, hoping it's not "just
>me" :)


if an app is running then its executable image, including DLLs are opened
and left open till it finished. This is because windows doesnt load
executables, it memory maps them and lets the pager demand page bits in.

There is a bit you can set in a windows PE header to tell the OS to copy exe
images (into swap space) before executing, but this bit is only listened to
when the drive from which the app is executing is marked as removable. Like
it's a CD-R or a floppy, and possibly a network drive (I forget). Maybe if
you set the bit and deploy to a network directory then the server will do
the right thing.

Regarding the original explorer issue, I suspect it may be possible to
broadcast a Plug&Play event to all toplevel windows to tell them the drives
have changed and they need to do something about it. This is, after all,
what happens when network drives come and go, and explorer copes with that.


Stefan committed a patch to Delete last week, adding a failonerror flag to
the task. I needed that so that at least when failure occurs it gets printed
to the screen while the deploy continues.

However, stopping the server, *renaming* the deployment directory tree, then
redeploying is still going to be your best bet for having a reliable
deployment process on win32.


View raw message