ShadowFolders not updating - Mutex errors

[tstanley]

I have configured the ShadowFolders I believe correctly to run as another user properly in the web.config:

<identity impersonate="true" userName="DOMAIN\someuser" password="somepassword" />

When running the Admin Tool I can succesfully set a shadow folder for a repository, set it for read only, and when the shadow is added, the shadowfolder correctly has files that mirror the repository. However, when files are added, or removed by vault client users, the shadowfolder is not updated .


The shadow folder is to a local drive on the same server that is running the Vault server.

I have updloaded the shadowfolder.log file which shows several vault errors creating mutex's.

Client Information
Vault Client Version: 2.0.1.2137
Operating System: Microsoft(R) Windows(R) Server 2003, Enterprise Edition
Service Pack: 0.0
OS Version: 5.2.3790
Total Physical Memory: 767.54 MB
Time Zone: (GMT-05:00) Eastern Time (US & Canada)

Server Information
Vault Server Version: 2.0.1.2137
Operating System: Microsoft(R) Windows(R) Server 2003, Enterprise Edition
Service Pack: 0.0
OS Version: 5.2.3790
Timezone: (GMT-05:00) Eastern Time (US & Canada)
SQL Version: Microsoft SQL Server 2000 - 8.00.760 (Intel X86)
Dec 17 2002 14:22:05
Copyright (c) 1988-2003 Microsoft Corporation
Developer Edition on Windows NT 5.2 (Build 3790: )

License Information
License ID: 0
Customer ID: 0
Number of Licenses: 10
License Type: Demo
Creation Date: 3/17/2004
Activated: N

License ID: 0
Customer ID: 0
Number of Licenses: 10
License Type: Demo
Creation Date: 4/13/2004
Activated: N

[mskrobul]

*Usually* when a shadow folder isn't getting updated after a commit from the Client it is a permisson problem.

Verify that DOMAIN\someuser has full permission to the shadow folder cache in DOMAIN\someuser's application data folder:

C:\Documents and Settings\someuser\ApplicationData\SourceGear\Vault_1\PluginWebService.

If that is not it and something is holding the mutex for some reason, closing down all Vault Client and Admin Tool instances (did you kill a previous version of Vault from the task manager?) on the server machine should cause the mutex to be released. If that fails, rebooting the machine will guarantee no mutexes are held, but usually this isn't required.

[tstanley]

I have exhausted several attempts for multiple options for versions of VAULT (2.01 and 2.02) and security configrurations, but the ShadowFolders feature is just not working for me .

This is really a critical feature for purchasing this product so any help resolving this or pointing me to a configuration that does work I would appreciate or any suggestions. Again, this is an important feature for me to approve purchasing this product for our organization.

Here is the use case scenario I would assume should work given a SHADOW FOLDER feature (i.e. this is what VSS does):
1) VAULT is installed with a ShadowFolder for a root level folder in a repository to mirror to lan network share or a local drive.
2) Files are added to the repository and they should be copied to the shadow folder.
3) Files are updated to the repository and the updates should be copied to the shadow folder.

The repository in use has 1288 revisions, 1174 files, and 162 folders. It was migrated from VSS succesfullly.

Here is what happens.
Configuring the Shadow Folder
1) The VAULT Web.config is configured to run as a user:
The VaultService web.conf is:
<identity impersonate="true" userName="SOMEDOMAIN\SOMEautomateduser" password="SOMEPASSWORD"/>
2) Log on the the server running IIS and VAULT as SOMEautomateduser.
3) Install the Admin tool under SOMEautomatedUser.
4) Log into the admin tool for vault as the VAULT admin user.
5) Configure a shadow folder for the repository.
6) Time passes, replicating the folders and files to the shadow folder.
7) I received an error The underlying connection was closed: An unexpected error occured on a receive.
There are various files in the shadow folder that have zero bytes.
9) Adding or removing files from other client systems / other users are not updated in the Shadow Folder.

Technical Support Information
Client Information
Vault Client Version: 2.0.2.2163
Operating System: Microsoft Windows XP Professional
Service Pack: 1.0
OS Version: 5.1.2600
Total Physical Memory: 511.16 MB
Time Zone: (GMT-05:00) Eastern Time (US & Canada)

Server Information
Vault Server Version: 2.0.2.2163
Operating System: Microsoft(R) Windows(R) Server 2003, Enterprise Edition
Service Pack: 0.0
OS Version: 5.2.3790
Timezone: (GMT-05:00) Eastern Time (US & Canada)
SQL Version: Microsoft SQL Server 2000 - 8.00.760 (Intel X86)
Dec 17 2002 14:22:05
Copyright (c) 1988-2003 Microsoft Corporation
Developer Edition on Windows NT 5.2 (Build 3790: )

License Information
License ID: 0
Customer ID: 0
Number of Licenses: 10
License Type: Demo
Creation Date: 3/17/2004
Activated: N

License ID: 0
Customer ID: 0
Number of Licenses: 10
License Type: Demo
Creation Date: 4/13/2004
Activated: N

[mskrobul]

Please email me your vault server log (sgvault.log in the sgvault folder located in your windows temp directory) and the shadowfolder.log file (in the shadow folder directory).

This may be easier to troubleshoot this over the phone. Please include your phone number in the email message and we will call you and hopefully get your problem resolved.

Use the email button at the bottom of this message to send the email message directly to me.

[tstanley]

Yet another set of tests. Recall the Web Server is running Windows Server 2003.

After multiple attempts (some got no files just directories, and deleting the cache and the shadow folder and the recreating the shadow folder, I was finally able to get the admin user on the server to create a shadow folder when I recieved again the error The underlying connection was closed: An unexpected error occured on a receive.

I examined how far off the shadowfolder was from what was in vault using a directory comparison tool. There were several files that were zero bytes. This is not a good sign for shadow folder integrity.

1) After deleting and adding the shadow folder back, this did not correct the zero byte files.

2) I deleted the zero byte files from the shadow folder, then deleted and added the shadow folder back to the repository. This time it fixed the missing files.

3) All was in sync and I was still logged in as the same user that runs the vault shadow service. I changed a file from another client / computer from the server Whoa to my suprise it actually copied the changed file to the shadow folder.

4) I logged out of VAULT admin on the server and logged the Domain user off of the vault server. I then added a new file as a different user and again to my suprise - it didn't copy it to the shadow folder.