Veracity Q&A home login about faq

I seem to be getting a lot of explorer hangs / slow UI and I've seen veracity_cache using a lot of CPU, is there an easy way to disable the veracity tortoise explorer plugin for a bit (without doing a full uninstall) while I see if this is the problem?

Note this seems to happen around two or three times during the day and I suspect it's when I plugin / remove some removable media (but it could also be because I used subst drive letters)

Also is there any good diagnostics I can do in the meanwhile?

asked Jan 30 '12 at 10:41

PeterI's gravatar image

PeterI
966813

edited Jan 30 '12 at 10:42


That is pretty disconcerting, so let's try to track down the problem first.

I would advise you to turn on verbose logging:

  1. On the command line, do: vv config set log/level verbose
  2. Kill the existing veracity_cache.exe.
  3. Then, you should be able to see what's going on in the log %LOCALAPPDATA%/Sourcegear/Veracity/Logs.

Please email me the log file, if you need help figuring out what's going on.

Some notes on performance.

  • The explorer integration should only examine fixed drives.
  • The veracity cache program should only be queried about files and folders inside a working folder (some parent folder contains a .sgdrawer file).

As for temporarily turning explorer integration off, I have used and liked ShellExView.

http://www.nirsoft.net/utils/shexview.html

link

answered Jan 30 '12 at 13:26

Jeremy%20Sheeley's gravatar image

Jeremy Sheeley ♦
74551323

Ok I'll try all of that tomorrow. I'm "blaming" veracity as its the last shell extension I installed but it could easily be something else (although the high CPU usage I saw made me wonder)

BTW I do subst drives so the same data appears three times.

(Jan 30 '12 at 15:04) PeterI

Ok this looks like it's probably a problem because I have substed drive. i.e. my project lives in a folder called C:DEMS but I usually have this substed to be P: i.e. I've run the command

subst p: c:dems

Worse if I kill explorer then the log gets filled with this message (which rapidly grows to multiple megabytes):

[2012/01/31 16:08:05.715 +0000] [PID: 7104, Thread: 4604] Error: Error occurred while calling ConnectNamedPipe to the client: 232
[2012/01/31 16:08:05.715 +0000] [PID: 7104, Thread: 4604] Error: Error occurred while calling ConnectNamedPipe to the client: 232

The log for the P: subst is below:

[2012/01/31 15:59:38.185 +0000] [PID: 6188, Thread: 7048] Verbose: ConnectNamedPipe() was successful.
[2012/01/31 15:59:54.221 +0000] [PID: 4252, Thread: 3232] veracity__cache started logging
[2012/01/31 15:59:54.233 +0000] [PID: 4252, Thread: 3232] Verbose: CreateNamedPipe() was successful.
[2012/01/31 15:59:54.693 +0000] [PID: 4252, Thread: 3232] Verbose: ConnectNamedPipe() was successful.
[2012/01/31 15:59:54.693 +0000] [PID: 4252, Thread: 3232] Verbose: ReadFile() was successful.
[2012/01/31 15:59:54.693 +0000] [PID: 4252, Thread: 3232] [ 0ms] [( 0/ 0) 0%] Operation: got client message
[2012/01/31 15:59:54.693 +0000] [PID: 4252, Thread: 3232] [ 0ms] [( 0/ 0) 0%] Verbose: Client sent the following message: {"command":"status","path":"C:/DEMS/"}
[2012/01/31 15:59:54.693 +0000] [PID: 4252, Thread: 3232] [ 0ms] [( 0/ 0) 0%] Operation: getting status
[2012/01/31 15:59:54.693 +0000] [PID: 4252, Thread: 3232] [ 0ms] [( 0/ 0) 0%] Value: path="C:/DEMS/"
[2012/01/31 15:59:54.693 +0000] [PID: 4252, Thread: 3232] [ 0ms] [( 0/ 0) 0%] Verbose: creating new treediff_cache object
[2012/01/31 15:59:54.702 +0000] [PID: 4252, Thread: 3232] [ 9ms] [( 0/ 0) 0%] Verbose: OS version is: 6.1
[2012/01/31 15:59:54.710 +0000] [PID: 4252, Thread: 3232] [ 0ms] [( 0/ 0) 0%] Operation: refreshing cached tree diff
[2012/01/31 15:59:55.152 +0000] [PID: 4252, Thread: 3232] [ 442ms] [( 0/ 0) 0%] Result: 0
[2012/01/31 15:59:55.152 +0000] [PID: 4252, Thread: 3232] [ 459ms] [( 0/ 0) 0%] Value: repo path="@/"
[2012/01/31 15:59:55.153 +0000] [PID: 4252, Thread: 3232] [ 460ms] [( 0/ 0) 0%] Value: diff value=true
[2012/01/31 15:59:55.153 +0000] [PID: 4252, Thread: 3232] [ 460ms] [( 0/ 0) 0%] Value: status returned=4
[2012/01/31 15:59:55.153 +0000] [PID: 4252, Thread: 3232] [ 460ms] [( 0/ 0) 0%] Result: 0
[2012/01/31 15:59:55.153 +0000] [PID: 4252, Thread: 3232] [ 460ms] [( 0/ 0) 0%] Verbose: Result is: {"status":4}
[2012/01/31 15:59:55.153 +0000] [PID: 4252, Thread: 3232] [ 460ms] [( 0/ 0) 0%] Result: 0
[2012/01/31 15:59:55.154 +0000] [PID: 4252, Thread: 3232] Verbose: ConnectNamedPipe() was successful.
[2012/01/31 15:59:55.154 +0000] [PID: 4252, Thread: 3232] Verbose: ReadFile() was successful.
[2012/01/31 15:59:55.154 +0000] [PID: 4252, Thread: 3232] [ 0ms] [( 0/ 0) 0%] Operation: got client message
[2012/01/31 15:59:55.155 +0000] [PID: 4252, Thread: 3232] [ 1ms] [( 0/ 0) 0%] Verbose: Client sent the following message: {"command":"status","path":"P:/"}
[2012/01/31 15:59:55.155 +0000] [PID: 4252, Thread: 3232] [ 0ms] [( 0/ 0) 0%] Operation: getting status
[2012/01/31 15:59:55.155 +0000] [PID: 4252, Thread: 3232] [ 0ms] [( 0/ 0) 0%] Value: path="P:/"
[2012/01/31 15:59:55.155 +0000] [PID: 4252, Thread: 3232] [ 0ms] [( 0/ 0) 0%] Result: 15
[2012/01/31 15:59:55.155 +0000] [PID: 4252, Thread: 3232] [ 1ms] [( 0/ 0) 0%] Result: 15
[2012/01/31 15:59:55.155 +0000] [PID: 4252, Thread: 3232] Error: Error 15 (sglib): Cannot get parent directory of root directory.
c:workssprawlpublicsrclibrariesutsg_pathname.c:1120
c:workssprawlpublicsrctortoiseveracity_cachesg_cache_application.cpp:461
c:workssprawlpublicsrctortoiseveracity_cachesg_cache_application.cpp:422
c:workssprawlpublicsrctortoiseveracity_cachesg_cache_application.cpp:347

[2012/01/31 15:59:55.155 +0000] [PID: 4252, Thread: 3232] Verbose: ConnectNamedPipe() was successful.

link

answered Jan 31 '12 at 10:26

PeterI's gravatar image

PeterI
966813

To be blunt, we didn't plan on subst, so I'm not shocked that there are problems. We're going to need to investigate that. At the moment, it would help to know if the .sgdrawer folder is located in P:.sgdrawer. We've had some bugs with working folders at the root of a drive.

(Jan 31 '12 at 11:33) Jeremy Sheeley ♦

Yep it's in the root of that drive. For me (personally) ignoring substed drives would work (i.e. treat them like removable) but I did bug some different problems with subst (see this post back in Nov)

http://veracity-scm.com/qa/questions/515/paths-and-case-sensitivity

I usually have p: substed as a "project" drive and r: for reference dlls (this stops silly references to things on C drives).

(Jan 31 '12 at 12:00) PeterI

Peter,

I've reproduced both the slowdown and the megabytes of logging when explorer is killed. I'll get back to you when I have a fix, or a workaround. Thanks for the report!

(Jan 31 '12 at 16:48) Jeremy Sheeley ♦

Good to hear that you can reproduce it. Nothing worse than a "it works on my machine" bug.

(Feb 01 '12 at 03:04) PeterI

Sorry meant to say that for now I've alter my subst pathing so it's no longer the root and life seems to be happier.

(Feb 01 '12 at 07:51) PeterI
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or __italic__
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Tags:

×24

Asked: Jan 30 '12 at 10:41

Seen: 1,262 times

Last updated: Feb 01 '12 at 07:51

powered by OSQA