Shadow folder problems

Jerry R · Post by **Jerry R** » Thu Jul 22, 2004 3:48 pm

I won't be able to experiment around with the privileges/groups/users until tomorrow, since our network guy left for the day already.

But here's some new information. I was wrong about Admin privileges having fixed the shadow folder updating. What I thought were indications in the log that it was working for people other than me was misleading. I don't really understand what's going on now. One of the developers here said they did a branch on a shared file and then checked out/in the file to update it. The sgvault and shadowfolder log files show no errors. However, the logs only mentioned files and folders being deleted -

Deleting file : \\Build-xpg\mm62\VInput\PCO\cam_types.h @ 22-Jul-04 15:25:42

File : \\Build-xpg\mm62\VInput\PCO\cam_types.h deleted! @ 22-Jul-04 15:25:42

But when I just had him check out a file in the same directory, change a character and check it back in, same old error.

Initializing Client Instance... @ 22-Jul-04 17:40:37

Client Instance Initialized! @ 22-Jul-04 17:40:37

Verifying Repository... @ 22-Jul-04 17:40:37

Repository verified! @ 22-Jul-04 17:40:37

Retrieving Delta... @ 22-Jul-04 17:40:37

Access to the path "SourceGear\Vault_1\PluginWebService\A7CE8FE7-EA85-4A4D-8759-CB054546D9FA\admin" is denied. @ 22-Jul-04 17:40:39

Post by **jclausius** » Thu Jul 22, 2004 3:55 pm

There's still a piece missing related to the vault-shadow Windows account. Its like it is not acting like a normal user. Perhaps we'll know more when your network admin is back.

Jerry R · Post by **Jerry R** » Fri Jul 23, 2004 10:59 am

The problem now appears to be fixed. vault-shadow was a member of the domain users group, and domain was a member of the local users group. But maybe the permissions didn't cascade?

What we did today was make vault-shadow directly a member of the local users group, and now (at least with minimal testing) we don't get the errors anymore and the file I experimented with gets updated on the build machine.

Does this make sense to have fixed the problem? Thanks for all your help, Jeff.

Post by **jclausius** » Fri Jul 23, 2004 12:00 pm

Yes, that makes perfect sense. The Custom Windows account (vault-shadow) didn't have all the necessary permissions for Shadow Folder to work correctly. Adding them to the Local Users group solved the problem.

Thanks for the assistance.

I'll update the KB article to include this tid-bit of information.

Jerry R · Post by **Jerry R** » Fri Jul 23, 2004 3:41 pm

Just when you thought it was over...

Examining the shadowfolder.log file, I'm seeing a bunch of errors of these two types:

Error: Local file update for $/MetaMorph/MM/App/MMProc/Dropins/grating.l failed: System.UnauthorizedAccessException: Access to the path "\\Build-xpg\mm\App\MMProc\Dropins\grating.l" is denied.
at System.IO.__Error.WinIOError(Int32 errorCode, String str)
at System.IO.File.InternalCopy(String sourceFileName, String destFileName, Boolean overwrite)
at VaultClientOperationsLib.WorkingFolder.UpdateWorkingFile(VaultClientFile file, Int64 targetVersion, Int64 displayVersion, MergeType merge, DateTime dt, Boolean makeBackups, OverwritePrompt PromptData)
at VaultClientOperationsLib.WorkingFolder.UpdateWorkingFile(VaultClientFile file, Int64 targetVersion, Int64 displayVersion, MergeType merge, DateTime dt, OverwritePrompt PromptData)
at VaultClientOperationsLib.ClientInstance.ProcessGetFileRequests(GetFileInfo[] infos, MakeWritableType makeWritable, SetFileTimeType setFileTime, MergeType merge, Boolean updateHiddenFilesOnly, String ancestorFullPath, String ancestorDiskPath, OverwritePrompt PromptData, Boolean isLabelGet, String currentPathToLabelItem, Int64 labelID) @ 23-Jul-04 16:13:31

Error: Local file update for $/MetaMorph/MM/UIC_DDM/hwprofile.xml failed: System.IO.IOException: The process cannot access the file "\\Build-xpg\mm\UIC_DDM\hwprofile.xml" because it is being used by another process.
at System.IO.__Error.WinIOError(Int32 errorCode, String str)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, Boolean useAsync, String msgPath, Boolean bFromProxy)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize)
at System.IO.File.OpenFile(String path, FileAccess access, IntPtr& handle)
at System.IO.File.SetLastWriteTimeUtc(String path, DateTime lastWriteTimeUtc)
at System.IO.File.SetLastWriteTime(String path, DateTime lastWriteTime)
at VaultClientOperationsLib.WorkingFolder.UpdateWorkingFile(VaultClientFile file, Int64 targetVersion, Int64 displayVersion, MergeType merge, DateTime dt, Boolean makeBackups, OverwritePrompt PromptData)
at VaultClientOperationsLib.WorkingFolder.UpdateWorkingFile(VaultClientFile file, Int64 targetVersion, Int64 displayVersion, MergeType merge, DateTime dt, OverwritePrompt PromptData)
at VaultClientOperationsLib.ClientInstance.ProcessGetFileRequests(GetFileInfo[] infos, MakeWritableType makeWritable, SetFileTimeType setFileTime, MergeType merge, Boolean updateHiddenFilesOnly, String ancestorFullPath, String ancestorDiskPath, OverwritePrompt PromptData, Boolean isLabelGet, String currentPathToLabelItem, Int64 labelID) @ 23-Jul-04 16:13:31

They don't seem to happen on every check-in, but when they do happen, there are a whole lot of them in a row.

Post by **jclausius** » Fri Jul 23, 2004 9:03 pm

Jerry:

Do you have a lot of transactions occur within a short time frame?

We're currently wrapping up a new Shadow Folder process model which is more adept at handling higher loads placed on the shadow folders.

Jerry R · Post by **Jerry R** » Mon Jul 26, 2004 9:37 am

I don't think there's enough data at this point to say. What's the best way to tell if there are a lot of transaction going on? And what is "a lot"?

Post by **jclausius** » Tue Jul 27, 2004 7:23 am

Jerry R wrote:I don't think there's enough data at this point to say. What's the best way to tell if there are a lot of transaction going on? And what is "a lot"?

If you wanted cold, hard facts, you would place the Server logging within "Debug" mode, and then watch the sgvault.log for begintx and endtx log entries.

By a lot, something in the order of 8+ transactions within a 1-2 second window?

To be honest, my question was exploratory in nature, it looks like we'll be releasing Vault 2.0.5 sometime soon, I wanted to see if some fixes we've made in Shadow Folder would also apply to your situation.

Jerry R · Post by **Jerry R** » Tue Jul 27, 2004 8:28 am

Actually, we've had the server logging in Debug mode for about a week now. I can tell you that when we had the errors I described a few messages back, in sgvault.log there were no BeginTx's closer together than 20 seconds or so in the time period that the errors were listed in the shadowfolder.log. There are a ton of entries in the sgvault.log, but not a lot of begintx's.

We'll certainly give Vault 2.0.5 a try when it's ready.

KKnoch · Post by **KKnoch** » Thu Jul 29, 2004 9:47 am

I work closely with TBreyman who has posted a couple of times here about problems we have been having. To refresh your memory we are installed a W2K3 server running IIS6. He has commented to me that even though we configure a Shadow folder for our test repository, it is not being populated with the data that is in the repository. I removed the shadow folder using the Admin tool and started again. Now when I try to add the shadow folder I get the following error:
"The attempt to download the files from the shadowed folder failed. Please check the Shadow Folder's error log for more information."
This only occurs when I choose the Folder in Repository to be $. When I drill down and choose a subdirectory it works fine.
The last line of the aforementioned error log is:
Failed to create mutex. errno=5 @ date
Thanks,
Kim
[/i]

Post by **jclausius** » Thu Jul 29, 2004 10:28 am

Kim:

The issue you're seeing has been addressed in Vault 2.0.5. If you are interested, the Vault 2.0.5 is in beta, which can be found at the following link: Vault 2.0.5 beta

Unless something major comes up, you can expect Vault 2.0.5 to be released shortly.

Post by **jclausius** » Thu Jul 29, 2004 10:35 am

I should note - The problem mentioned abouve about releasing the mutex requires you to upgrade your Server (Shadow Folder Web service) to Vault 2.0.5.

The Vault 2.0.5 Server Beta is not yet posted. I'll update the previous post when it becomes available.

Post by **jclausius** » Thu Jul 29, 2004 2:42 pm

Latest Vault 2.0.5 (Preview 2201):

Vault Client 2.0.5 Preview 2201

Vault Server 2.0.5 Preview 2201

A couple of notes:

1) You will need to un-install / re-install both client and server. (Please keep your database during un-installation and do not DROP the database during re-installation). There are updates to the *.config files, which an upgrade will handle.

2) After installation, but before re-configuring shadow folders, enable all logging within the shadow folder web.config file. Important: Read this KB article for instructions - http://support.sourcegear.com/viewtopic.php?t=1534.

3) Finally, re-configure your shadow folder associations from within the Admin Tool.

That should be about it. If you have any problems / questions, just post to the forum.

KKnoch · Post by **KKnoch** » Fri Jul 30, 2004 6:30 am

Is this still beta or is this the final release?

Thanks for your help.

Post by **jclausius** » Fri Jul 30, 2004 6:46 am

KKnoch wrote:Is this still beta or is this the final release?
Thanks for your help.

Officially, we're calling this "Preview 2201". There are some final items which need to be "tidied up". But assuming no one encounters any problems with the Preview, an RTM version is right around the corner.

SourceGear Support

Shadow folder problems

More Shadow folder problems

2.0.5 preview 2201

Re: 2.0.5 preview 2201