Target File Locked on Midpoint Prevents Updates from the Source

• Microsoft Site Server version 3.0
• Microsoft Site Server version 3.0, Commerce Edition

SYMPTOMS

Automatic projects never replicate the contents, and the checkpoints never check the file again to confirm whether it has been updated or not. For example, when you have a source-midpoint-endpoint configuration and you are replicating a file to the midpoint, if you update the file on the source computer as soon as it's done replicating to the midpoint, the file will be locked on the midpoint system, because the midpoint is attempting to replicate the file to the endpoint. When replication from the source to the midpoint occurs, this lock prevents the file from being updated, and further updates are not replicated to the endpoint. This can occur if the network link is slow, because the lock remains in effect while replication is taking place.

Furthermore, the midpoint system will have garbage located in the Crstemp directory that will accumulate while the system remains running. The following file will appear to accumulate:

\crstemp\projectdirname\99\99\file*

CAUSE

PerformMoveTransaction goes through the processing and fails. The routine that performs the MoveFileEx api returns that an ERROR_SHARING_VIOLATION and CRS_ERROR_FILE_MOVE_ERROR has occurred .

RESOLUTION

To resolve this problem, obtain the latest service pack for Site Server 3.0. For additional information, please see the following article in the Microsoft Knowledge Base:

Q219292 How to Obtain the Latest Site Server 3.0 Service Pack

WORKAROUND

Updates to project files that are replicated from the source system to the midpoint system cannot occur while replication from the midpoint to the endpoint system is in progress. They must be scheduled synchronously, which typically occurs on a fast local area network (LAN), and thus prevents the problem.

STATUS

This problem was first corrected in Site Server 3.0 Service Pack 3.

MORE INFORMATION

The Crs LockedFilesTimeout value is used as a global parameter that applies to all projects located on the system. The project level value will override the global value for the specific project if it is present. The value for LockedFilesTimeOut is read as a String. The fix now includes a 30 second retry period by default.

WARNING: Using Registry Editor incorrectly can cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk.

For information about how to edit the registry, view the "Changing Keys and Values" Help topic in Registry Editor (Regedit.exe) or the "Add and Delete Information in the Registry" and "Edit Registry Data" Help topics in Regedt32.exe. Note that you should back up the registry before you edit it. If you are running Windows NT, you should also update your Emergency Repair Disk (ERD).


The Global Crs value is located in the following registry key:

HKEY_LOCAL_MACHINE\Software\Microsoft\CRS

Software\Microsoft\CRS\Projects\Test\LockedFilesTimeOut

44/28/99 10:01:30 WRN 32 423 Moving c:\ProjectDir\CRSSRV.LOG to c:\CRSTemp\ProjectDir\00\01\0000007
4/28/99 10:01:30 WRN 32 423 MoveFileInternal @E:\inet2fre\pubsys\crs\crsdll\transact.cpp
The process cannot access the file because it is being used by another process.
4/28/99 10:01:30 WRN 32 423 PerformMoveTransaction @E:\inet2fre\pubsys\crs\crsdll\transact.cpp The process cannot access the file because it is being used by another process.
4/28/99 10:01:30 DBG 0 423 EVENT (15119): Failed to move file c:\CRSTemp\ProjectDir\00\03\0000006b.FIL to c:\ProjectDir\CRSSRV.LOG.

Additional query words:

Keywords : SS3SP3Fix
Version : winnt:3.0
Platform : winnt
Issue type : kbbug