File operations not happening in sequence

  • Thread starter Thread starter Bob Kline
  • Start date Start date
B

Bob Kline

We have noticed the following anomalous behavior often enough that we no
longer think we were just imagining things when it happens. In quick
succession (to minimize the amount of down time for our users), we
invoke from time to time the following commands from a command-line
console on one of our servers:

NET STOP service-name
REN service-name.exe service-name-filedate.exe
COPY \\otherserver\share\service-name.exe
NET START service-name

From looking at the responses to the commands in the console window,
everything appears to have taken place was we expected it would. The
service stopped when we asked it to. The old version of the server
binary was successfully renamed. The new version got copied into place
successfully. The service started back up fine. So we report back to
our users that the new enhancement (or bug fix, or whatever) is in place.

After a while, though, we start getting reports from our users that make
it clear that the new enhancement is actually _not_ in place, and the
service started with the old binary.

At this point, we issue the commands

NET STOP service-name
NET START service-name

and this time the service uses the new binary.

It's as if the file system is queueing up our RENAME/COPY commands, but
not actually performing them right away, even though it comes back
immediately with the claim that it has done so.

Has anyone else observed this behavior? Is this a known bug in Windows
2000? Does the OS have any way to say "really copy (or rename) this
file *now*"?

Thanks for any light any of you can shed on this mystery!

Windows 2000 Advanced Server, Service Pack 4
Compaq Proliant ML370, 4GB, 2-way 1400Mhz
Raid 5

Bob Kline
 
Sounds linke Windows File Protection
Is the service-name.exe in the C:\WinNT\SYSTEM32\DLLCACHE

See tips 2074 - 2076 in the 'Tips & Tricks' at http://www.jsiinc.com

If it is, first copu to the DLLCACHE older, followed by the System32 folder.

We have noticed the following anomalous behavior often enough that we no
longer think we were just imagining things when it happens. In quick
succession (to minimize the amount of down time for our users), we
invoke from time to time the following commands from a command-line
console on one of our servers:

NET STOP service-name
REN service-name.exe service-name-filedate.exe
COPY \\otherserver\share\service-name.exe
NET START service-name

From looking at the responses to the commands in the console window,
everything appears to have taken place was we expected it would. The
service stopped when we asked it to. The old version of the server
binary was successfully renamed. The new version got copied into place
successfully. The service started back up fine. So we report back to
our users that the new enhancement (or bug fix, or whatever) is in place.

After a while, though, we start getting reports from our users that make
it clear that the new enhancement is actually _not_ in place, and the
service started with the old binary.

At this point, we issue the commands

NET STOP service-name
NET START service-name

and this time the service uses the new binary.

It's as if the file system is queueing up our RENAME/COPY commands, but
not actually performing them right away, even though it comes back
immediately with the claim that it has done so.

Has anyone else observed this behavior? Is this a known bug in Windows
2000? Does the OS have any way to say "really copy (or rename) this
file *now*"?

Thanks for any light any of you can shed on this mystery!

Windows 2000 Advanced Server, Service Pack 4
Compaq Proliant ML370, 4GB, 2-way 1400Mhz
Raid 5

Bob Kline


Jerold Schulman
Windows: General MVP
JSI, Inc.
http://www.jsiinc.com
 
Jerold said:
Sounds linke Windows File Protection
Is the service-name.exe in the C:\WinNT\SYSTEM32\DLLCACHE

No, it doesn't participate in the file protection cache mechanism.

Bob
 
Back
Top