Operation Failed by updating file list

[spichr1613]

Hello,

we run SOS on Windows 2000 Advanced Server and using VSS2006 d.

Some user have the problem that they are not able to see all the files in a specific directory. If they try to update the file list they get the error message:

Operation failed....

If they try to view one of visible files than the client crashes:

4.12.2008 11:13:43 - 04.12.2008 11:13:43 - Server Exception (400): OPERATION_FAILED
04.12.2008 11:13:43 - 2: Server Error: 400
04.12.2008 11:14:03 - 2: Exception: Eine vorhandene Verbindung wurde vom Remotehost geschlossen
04.12.2008 11:30:06 - Connection accepted from 10.0.6.91:1424, session id is 3.

By using VSS evrything works fine.

Any Idea?

Regards

Christine

[lbauer]

What version of SOS Server and Client are you using?

Is this problem reproducible? Does it happen on the same file list to any user?

Is it a new problem -- was it working before?

If you use an SOS Client on the SOS Server machine, and login using "localhost" for the SOS Server name, can you see/get the files?

[spichr1613]

What version of SOS Server and Client are you using?
Server is 4.0 - clien 4.2

Is this problem reproducible? Does it happen on the same file list to any user?
Yes it is reproducible an it happen on the same file list to any user.

Is it a new problem -- was it working before?
Yes it is a new problem since some days

If you use an SOS Client on the SOS Server machine, and login using "localhost" for the SOS Server name, can you see/get the files?
On the local host it is almost the same behavior with the difference that SOS don´t crash. We see the same uncomplete file list.
Here the server log:

05.12.2008 09:11:46 - Connection accepted from 10.0.0.243:4565, session id is 73.
05.12.2008 09:12:44 - 05.12.2008 09:12:44 - Server Exception (400): OPERATION_FAILED
05.12.2008 09:12:44 - 73: Server Error: 400
05.12.2008 09:15:29 - 05.12.2008 09:15:29 - Server Exception (401): [$/master/product/server/src/com/pass/product/rez/server/process/manager\ResourceManager.java] - NO_SUCH_FILE_OR_PROJECT
05.12.2008 09:15:29 - 73: Server Error: 401
05.12.2008 09:15:40 - 05.12.2008 09:15:40 - Server Exception (400): OPERATION_FAILED
05.12.2008 09:15:40 - 73: Server Error: 400
05.12.2008 09:15:43 - 05.12.2008 09:15:43 - Server Exception (400): OPERATION_FAILED
05.12.2008 09:15:43 - 73: Server Error: 400
05.12.2008 09:17:09 - 05.12.2008 09:17:09 - Server Exception (400): OPERATION_FAILED
05.12.2008 09:17:09 - 73: Server Error: 400
05.12.2008 09:17:13 - 05.12.2008 09:17:13 - Server Exception (400): OPERATION_FAILED
05.12.2008 09:17:13 - 73: Server Error: 400
05.12.2008 09:17:15 - 05.12.2008 09:17:15 - Server Exception (400): OPERATION_FAILED
05.12.2008 09:17:15 - 73: Server Error: 400
05.12.2008 09:17:16 - 05.12.2008 09:17:16 - Server Exception (400): OPERATION_FAILED
05.12.2008 09:17:16 - 73: Server Error: 400
05.12.2008 09:18:15 - 05.12.2008 09:18:15 - Server Exception (400): OPERATION_FAILED
05.12.2008 09:18:15 - 73: Server Error: 400
05.12.2008 09:18:18 - 05.12.2008 09:18:18 - Server Exception (400): OPERATION_FAILED
05.12.2008 09:18:18 - 73: Server Error: 400
05.12.2008 09:18:29 - 05.12.2008 09:18:29 - Server Exception (401): [$/master/product/server/src/com/pass/product/rez/server/process/manager\ResourceManager.java] - NO_SUCH_FILE_OR_PROJECT
05.12.2008 09:18:29 - 73: Server Error: 401

Regards

Christine

[lbauer]

The SOS Client keeps a cache of the project tree. It is not automatically updated because this would take a lot of time/bandwidth. It's possible something changed in VSS, but the project tree view was not refreshed in SOS.

Have your users open the SOS Client, select the root project, $/, then in the menu bar, select View->Refresh Project Tree. This may take a while.

Let me know if this does not resolve the problem.

[spichr1613]

Hi Linda,

they refreshed the project tree on the root directorty but it is still the same behavior.

Regards

Christine

[lbauer]

The next step would be to run Analyze on the VSS database:

http://support.sourcegear.com/viewtopic ... p=111#p111

[spichr1613]

Hello,

we run analyze.exe in the repair version but we have still the same problem.

Regards

Christine

[lbauer]

Before we troubleshoot further, I'd recommend you upgrade your SOS Server to version 4.2, the latest version. If you continue to experience the crash, then send a copy of the log file to support at sourcegear.com, Attn: Linda.

[spichr1613]

Hello Linda,

we updated server and client but we have still the same problem. Please find attached the logfile and an screenshot.

Regards

Christine

[lbauer]

You have a number of errors that say "file or project not found." This means SOS Server is having problems getting information from the VSS database via the SourceSafe API.

Have you run Analyze recently on your database?

http://support.sourcegear.com/viewtopic.php?f=14&t=50

[spichr1613]

Hello Linda,

yes we did run analyze on the database. Some errors were found but there is no way to fix them. By using VSS we dont´t have any problems with these errors.

Please find attached the anlayze log file.

Regards

Christine

[jclausius]

Christine:

My name is Jeff Clausius, currently one of the developers for the upcoming release of SourceOffSite 5.

Looking at your previous error - "NO_SUCH_FILE_OR_PROJECT". This occurs on a file list when the SourceOffSite server asks the MS VSS library to look up a folder. So, the MS VSS library is reporting that the file, ResourceManager.java is not there.

In regards to anaylyze, the log states, "Potentially serious errors or inconsistencies were found." We'll need to take care of these problems first before we can proceed with anything else. What arguments did you pass to analyze? Did you pass any flags to fix the VSS database?

[spichr1613]

Hello Jeff,

we used these arguments: -C-D-F-V1. F schould repairs any inconsistencies and corruption that are detected. But it seems that the problem with the missing files can´t be fixed by this option. The only thing we could do is to insert the missing files from an older version. But than we will have maybe problems with the history.

Regards

Christine

[Beth]

The reason why they are asking to look more closely at Analyze is that the VSS automation component is far more sensitive to little things in the VSS database than the VSS client is. Third party tools have to use the VSS automation component to connect.

One thing that will help determine if something isn't quite right with the file in the database is to create a new blank VSS database, then archive the area of the old database that is causing the problem (or the entire database), and restore it to the new VSS database. Then add the new database to the SOS Server Manager and try to get the same problem files, but from the new database. The archive/restore function will sometimes repair small inconsistencies so that it restores properly.

If it works in the new database, then you could either archive/restore the entire VSS database (if you haven't already) to a new blank one and use that new one as the production database, or you could try analyze again, but run analyze -C -D -F -V4 X:\Some path to\VSS\Data >> VSSoutput.txt (replace X:\Some path to\VSS\Data with the path to the data portion of your VSS database) and look through the text file you've redirected the results to for any errors still listed. If there are errors, then run the same command a second time and check again for errors. Feel free to post that text file here or the errors.

Finally, could you tell me what the entire version number of your VSS automation component is? Instructions for finding that information are posted here: Automation Component Version.