remote shadow folders

rilles · Post by **rilles** » Fri Oct 14, 2005 2:22 pm

I'm trying to figure out one aspect of vault that I cannot get to work.

I've setup shadow folders, local ones work remote does not.

I've used the IdentitySwitcher.exe tool.

I have a drive mapped as such: "\\remote-server\test"
and another one mapped to "d:\test"

If I check in to the one mapped to d:\test, it works.

But I cannot seem to get the remote map to work..

Looking at the logs, the d:\temp invokes some shadowfolder.asmx thing, while the remote one does not, no errors just nothing happens

how can I fix this?

lbauer · Post by **lbauer** » Fri Oct 14, 2005 4:14 pm

What version of Vault are you using?

Are you using identity impersonation for the Shadow Folder service?

For folders to be shadowed on a different machine, the Shadow folder service needs to use a domain account. This is configured in the web.config file in the VaultShadowFolder directory. Uncomment the Identity impersonate section and enter a domain user account and password.

The best way to do this is to run the IdentitySwitcher:
http://support.sourcegear.com/viewtopic.php?t=2953

Instead of pointing it to the Vault Service web.config, edit the path in the tool to the VaultShadowFolder web.config. This will ensure the account has adequate permissions.

Also make sure the domain account has read/write access to the Vault shadow folder location.

If that's not the problem, check in the %windir%\temp directory on the Vault server machine for a VaultShadowFolderService.txt file and any errors in that file.

rilles · Post by **rilles** » Mon Oct 17, 2005 3:44 pm

I am using 3.1.2.3511

"Instead of pointing it to the Vault Service web.config, edit the path in the tool to the VaultShadowFolder web.config. This will ensure the account has adequate permissions. "

This is the magic line that made shadowing work.

I know have one more question:

If the shadowed file on the remote server is locked (ie a user is using the .exe file), how does the vault handle this?

From my testing it seems it ignores the issue. The vault internal file gets updated but the shadowed file does not.

Is not not a way for the vault to catch this error and report it back to the user? otherwise the file he thinks is there... is not!

lbauer · Post by **lbauer** » Mon Oct 17, 2005 6:33 pm

Vault may simply log an error in the shadow folder log (VaultShadowFolder.txt). You can check this by enabling additional logging; instructions here:

http://support.sourcegear.com/viewtopic.php?t=1534

I'd suggest logging all classes to be sure you capture the error. Be sure to turn off debug logging if you don't need it; the log can get large.

rilles · Post by **rilles** » Tue Oct 18, 2005 8:47 am

Ok, the logs clearly indicate there is an error and the the server knows about it. Why is the client not notified?

The end user merrily thinks everything is good - but it is not and doesn't know about it. VSS will report an error message to the end user when this happens.

Is there a setup on the client that can be changed?

lbauer · Post by **lbauer** » Tue Oct 18, 2005 9:06 am

Why is the client not notified?

This is the first request we've had for notification beyond the log files. I can log it as a feature request. Who would be the "end user" in this case - the Admin who set up Shadow Folders, or the user who did the last checkin?

Another consideration: Vault doesn't expect files in the Shadow Folder to be locked or edited by a third party. Shadow Folders should be used as a read only version of what is in the database.

rilles · Post by **rilles** » Tue Oct 18, 2005 9:22 am

The client in our case would be the user who did the last checkin.

The shadowed file should never be locked by a 3rd party in our scenario, but a rouge user could attempt this.

I hope this feature makes it in, Vault seems superior to VSS in every case we look at. This is the only case where I have found VSS and Vault differ in behaviour that is a negative point in our evaluation.

Richard