----- Original Message ----- From: "Butch Clark" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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. We >have noticed that on Win2k the file locking can be a REAL problem. There have >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 what >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" :) <win32-hacker-mode> 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. </win32-hacker-mode> 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. -Steve
