I had been having difficulty with VaultClient on WindowsXP. Simply bringing app to foreground would result in a hang for 15-20 secs, with 100% cpu usage. I have traced the problem to INTENSE file reads (and a few writes) to the j:\csc\... directory chain, which is the location of my Offline Files cache for windows offline files. My source code is stored on a server and I have the main drive mapped to my Q drive with the shared offline files cached at the j:\csc\... directory path.
The VaultGUIClient is completely unusable given the delays. I have no idea why it wants to read all the files I have every time I simply bring the app to the foreground, click on a file, change to a different folder, etc. Can this be addressed? Is there a setting I can change to eliminate this behavior?
Kevin
Windows Offline Files
Moderator: SourceGear
-
TheSQLGuru
- Posts: 10
- Joined: Tue Feb 07, 2006 10:10 am
- Contact:
We'll need to know more about your repository and client.
1. First, what version of Vault are you using? In fact, can you post the output of Help->Technical Support?
2. Do you have a large number of files in the pending change set?
3. By "offline files cache", do you mean a working folder that is associated with a Vault repository folder?
4. If you login on a different machine, do you get the same results? If someone else logs in on your machine, do you get the same results?
1. First, what version of Vault are you using? In fact, can you post the output of Help->Technical Support?
2. Do you have a large number of files in the pending change set?
3. By "offline files cache", do you mean a working folder that is associated with a Vault repository folder?
4. If you login on a different machine, do you get the same results? If someone else logs in on your machine, do you get the same results?
-
TheSQLGuru
- Posts: 10
- Joined: Tue Feb 07, 2006 10:10 am
- Contact:
1) I was using 3.1.6.xxx. I downloaded and installed the very latest flavor just last night and get the same reads of the offline files. 3.1.7.3719 is the specific version number
2) I get the same action with no files modified. I currently have 5 files that have 'edit' by them.
3) I am speaking of reads relating to WINDOWS OFFLINE FILES. It is a built in feature of windows xp. You can make files from one folder on a server or some other computer appear to be available on your computer even though you are disconnected. Those files get stored in a windows folder CSC, which I have on my J drive. VaultClient seems to want to read every file and write some too in that cache directory, even if all I do is bring the application to the foreground in windows. If I bring another app to the fore and then switch back to VaultClient - it repeats the reads. If I click on a file in the client, it repeats the reads - LOTS of them (hundreds and hundreds). I monitored these using FileMon, a tool from Winternals.
4) I do not have another machine with Vault. Everything is on one laptop. Database is tiny and is not the issue here, nor is file fragmentation. I have also switched from .NET 2.x back to 1.x, same results.
Kevin
2) I get the same action with no files modified. I currently have 5 files that have 'edit' by them.
3) I am speaking of reads relating to WINDOWS OFFLINE FILES. It is a built in feature of windows xp. You can make files from one folder on a server or some other computer appear to be available on your computer even though you are disconnected. Those files get stored in a windows folder CSC, which I have on my J drive. VaultClient seems to want to read every file and write some too in that cache directory, even if all I do is bring the application to the foreground in windows. If I bring another app to the fore and then switch back to VaultClient - it repeats the reads. If I click on a file in the client, it repeats the reads - LOTS of them (hundreds and hundreds). I monitored these using FileMon, a tool from Winternals.
4) I do not have another machine with Vault. Everything is on one laptop. Database is tiny and is not the issue here, nor is file fragmentation. I have also switched from .NET 2.x back to 1.x, same results.
Kevin
-
TheSQLGuru
- Posts: 10
- Joined: Tue Feb 07, 2006 10:10 am
- Contact:
Suprised you haven't tested for that given the increasing numbers of disconnected workers these days. 
In any case, is there an easy way to repoint everything to a new copy of the same files? I can copy the files to a new, local, directory tree very easily obviously. But do I have to reimport or go through the whole initialization process with Vault that I did initially or can I do something under the covers to make Vault know that the physical files are now in a new location?
In any case, is there an easy way to repoint everything to a new copy of the same files? I can copy the files to a new, local, directory tree very easily obviously. But do I have to reimport or go through the whole initialization process with Vault that I did initially or can I do something under the covers to make Vault know that the physical files are now in a new location?
If you stored your baseline files underneath the working folder, just moving them would suffice. However, this is not the default - baseline files are normally stored in the client cache somewhere under Docs & Settings.
In that case, you'll want to copy the files over to the new location and set the new working folder. The files will all be Unknown at that point, but a Get Latest should resolve all their states without having to re-retrieve every file (it should determine that the files match known versions in Vault). You should do a status search (by "Any Status") afterwards though to verify it worked correctly.
In that case, you'll want to copy the files over to the new location and set the new working folder. The files will all be Unknown at that point, but a Get Latest should resolve all their states without having to re-retrieve every file (it should determine that the files match known versions in Vault). You should do a status search (by "Any Status") afterwards though to verify it worked correctly.
-
TheSQLGuru
- Posts: 10
- Joined: Tue Feb 07, 2006 10:10 am
- Contact:
Well, the files are moved and repointed and VaultClient is MUCH more responsive.
However, I strongly encourage you to use FileMon and watch what happens when you bring VaultClient to the foreground - NO other action other than that and it reads in information about every file in the currently selected folder. Why? This seems to be grossly inefficient (can't imagine why it would be necessary either), and even for a local hard 7200rpm disk it is taking ~3 seconds for the 1221 files I have in one directory. Is there some setting that is making it do this I can turn off? Why would simply activating the app make it scan all the files on disk?
However, I strongly encourage you to use FileMon and watch what happens when you bring VaultClient to the foreground - NO other action other than that and it reads in information about every file in the currently selected folder. Why? This seems to be grossly inefficient (can't imagine why it would be necessary either), and even for a local hard 7200rpm disk it is taking ~3 seconds for the 1221 files I have in one directory. Is there some setting that is making it do this I can turn off? Why would simply activating the app make it scan all the files on disk?
When we refresh the window, we want to make sure that the state of the files is correct in current folder, so we check the datetime stamp of each file to update its status.
Are you using CRCs or timestamps to determine whether a file is edited? (Tools->Options->Local Files). CRCs will take a little longer.
Nonetheless, we'll take a look at this as well, and see if there is anything we are doing that is unnecessarily slow us down.
Are you using CRCs or timestamps to determine whether a file is edited? (Tools->Options->Local Files). CRCs will take a little longer.
Nonetheless, we'll take a look at this as well, and see if there is anything we are doing that is unnecessarily slow us down.