Configure automatic handling of network file sharing violations

A sharing violation happens when one program requests exclusive access to a file (ex. to write to the file), while another program is already having the file open (ex. to read the file). When a sharing violation happens on a local file, then the request for write-access will fail at once.
When a sharing violation happens on a network file, then the Server service on the remote machine will detect the sharing violation, but instead of failing right away, then it retries to open the file with certain intervals.

This retry mechanism is quite nice when using programs in a network environment, which haven't been made to handle sharing violation, as it will lower the "visible" sharing violations. If the programs trying to access the same file is already capable of handling the sharing violation, with their own retry mechanism, then this change in behavior with network files might interfere, and lower performance.

[HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \LanmanServer \Parameters]
SharingViolationDelay = 200 (Default = 200 ms)
SharingViolationRetries = 5 (Default = 5)

More Info MS KB150384
More Info MS KB889588

Note it is strange that Microsoft have implemented this polling strategy, incase several programs are trying to request the same file, then one or more programs might experience that they never gets access because between each delay another program "steals" the access.



  1. cumulus says:

    My need is to have one macro writing periodically to a file and have another macro on another PC copy that file, neither macro to interfere/crash the other. This article seemed to offer a solution. However, SharingViolationDelay/Retries do not exist either under lanmanserver or workstation in the registry in my XP Pro, Office 2000 environment. I use Excel 2000 because it is multiples faster than Excel 2003 and especially many multiples faster than Excel 2007.

    Help would be much appreciated.

  2. snakefoot says:

    My need is to have one macro writing periodically to a file and have another macro on another PC copy that file, neither macro to interfere/crash the other.

    If the problem is that the other PC shouldn't access the file before the other is finished, then you could use a "locking" file.

    • PC1 wants to write a file, so creates a dummy file ex. "xsllock" and then starts to write the data file.
    • PC2 polls for new files it hasn't seen, when it sees a new data files then it only access the data files if the dummy file "xsllock" doesn't exist.
    • PC1 finishes the writting of the data file and then deletes "xsllock".
    • PC2 is polling for the "xsllock" file to disappear, and when it does then it will access the data file.

    In case the PC1 is capable of writting several new data files, then PC2 can assume that when newer data files exists, then doesn't have to wait for the "xsllock" file to disappear when reading old data files.

    In case there is only one data file, then PC2 should create a locking file to block PC1 from overwritting the data file while reading the data file.

    P.S. The registry setting described isn't created by default, and should only be changed in special environments as it will change the behavior for all applications on the machine.

Leave a Reply

Your email address will not be published. Required fields are marked *