soscmd errors

kurtgo · Post by **kurtgo** » Sat Sep 24, 2005 5:33 pm

I get an error while trying to check out a whole project tree. I don't have any issues with the GUI (works fine, no errors).

Occasionally soscmd will finish without errors, but it is rare. The directory is 8mb of data, and it usually gets about 4mb into the get and then fails. The average file size is 20kb for all of the files.

Any help solving this would be much appreciated, as I'm dead in the water until I find a workaround. I have tried -nocompress -nocache, and neither. I have tried with/without the -label also. All combinations yield errors, but at different spots in the file list.

Here is the command and it's verbose output (some of it was clipped for brevity).

"C:\Program Files\SourceOffSite\soscmd.exe" -command GetProject -server server:8890 -name test -password "" -database c:\VSS\srcsafe.ini -project $/project -soshome "C:\Program Files\SourceOffSite" -workdir "c:\test" -label "testlabel" -recursive -verbose -nocache

SourceOffSite Command Line Client: 128 bit Encryption version 4.1
Connected to server server1.home at port 8890.
Received Secure Challenge from server
Successfully logged in.
Sending GetProject Command to server.
Got file: c:\test\test.cpp
... clipped ...
Got file: c:\test\testmob.cpp
Net error during attempt to read headers. (RH2). Error: 0
Got file: c:\test\test\ChartCtrl.h
Could not open file \s3r4.7h. Error Num=2
Error: Server response = 203 File
Closed connection to server server1.home at port 8890.

bfinney · Post by **bfinney** » Mon Sep 26, 2005 3:15 pm

Before I dig very deeply into this, could I get you to upgrade your CLC to 4.1.2? We made a ton of changes to the command line client for 4.1.2, and overall it's much more stable than 4.1.

kurtgo · Post by **kurtgo** » Tue Sep 27, 2005 10:25 am

The good news, it gets farther before it errors out.
The bad news, it still errors out.

I think it might be some sort of connection timeout, as it seems to run for about 1 minute and then error out.

It gets about 6MB of the 8MB with 4.1.2

The connection from the client to the server is over two cable modems running 3000kbps.

I looked at some old posts, and it appears that others have had this problem in the past, but no resolution was posted (searched "error AND 203")

bfinney · Post by **bfinney** » Tue Sep 27, 2005 2:59 pm

Yeah, it does sound like the connection is being killed prematurely. If you can, please send us (or have a colleague send us) a copy of the SOS server log - it should contain some evidence if the killed connections are the cause and not the effect.

kurtgo · Post by **kurtgo** » Tue Sep 27, 2005 5:54 pm

I wrote a perl script to just get the project tree, then do a non-recursive get on each branch. It fails on the same file consistently, and the get that fails only takes a couple of seconds, so I think that rules out a timeout.

I'm working on getting the server logs (they are at another site, and I have to wait on them).

kurtgo · Post by **kurtgo** » Tue Sep 27, 2005 8:58 pm

when it fails, the server (with verbose mode) says:
Tue Sep 27 20:53:33 MDT 2005 - xxxxx (xx.xx.xx.xx) - Unable to get file by label: $/project/testdir/testfile

and the client give same error above (the files match that are wrong, but are different files with each run).

no other errors appear in the log.

the command line does leave droppings the root directory also. Files that start with "s" like "s2rc.1m" every time it fails.

Also, I modified the perl script to retry up to 10 times on each project, and it mostly works (albeit very slow).

kurtgo · Post by **kurtgo** » Thu Oct 06, 2005 7:03 am

hello!?

bfinney · Post by **bfinney** » Fri Oct 07, 2005 8:02 am

Sorry for the delay.

If you're getting "Unable to get file by label" errors in the GUI client as well, the problem certainly lies on the server side.

The first thing to do would be to run the VSS analyze utility on your database with the -f and -c switches. The SourceSafe automation component (which the SOS server uses to interact with VSS) is extremely sensitive to corruption - far more so than "normal" SourceSafe clients.

Labels are particularly sensitive to corruption, so I'd guess that there's about an 80% chance analyze will take care of the problem

kurtgo · Post by **kurtgo** » Fri Oct 07, 2005 3:54 pm

I would believe that, but when I re-send the same command it works (may take several attempts). This leads me to believe that it is a problem with your communication link with the SOS server, not the VSS database.

BTW, I did run analyze and found no errors.

kurtgo · Post by **kurtgo** » Fri Oct 07, 2005 4:00 pm

more fuel for the fire: I had another person try the same checkout command (different network, but connecting to the same server), and it failed in the same way.

I don't have any problems with other connections like massive downloads of data, uploads, etc. etc., including the GUI SOS. Therefore, I don't think there can be any blame on the connection/transport.

Regards,
Kurt

kurtgo · Post by **kurtgo** » Thu Nov 03, 2005 1:04 pm

well, I assume this issue is filed in the vertical folder

lbauer · Post by **lbauer** » Thu Nov 03, 2005 4:44 pm

We haven't given up on you; it's just that these things are hard to diagnose, once we've been through all the usual solutions.

There may be a network issue, or it could be a problem with the VSS automation component. Those are things we have little control over.

I'll contact one of our SOS developers and see if he can weigh in here with more ideas.

Meanwhile, could you confirm if you've gotten the same results using SOS 4.1.2 CLC and SOS Server?

corey · Post by **corey** » Mon Nov 07, 2005 3:41 pm

Hi Kurt,

I read over this entire thread. Here are the details which stuck out to me:

1. This problem only occurs for you with the command line client. You do not have any problems using the GUI client on the same projects. Is that still correct?

2. The error reported in the server log is "unable to get file by label" but from what I read in your post on 9/27, each run of your script gives a different file name for the cause of the error. Is that still correct, too?

Can you temporarily modify your script to try the following? Rather than have the script execute a Get on each branch of the project, just have it do a Get on one of the branches that contain one of the files that previously caused the error, and then do nothing more. If that succeeds, then try modifying your script again to log out and log back in between each Get for each branch. Perhaps resetting the connection between Gets would prevent the error you are seeing.

kurtgo · Post by **kurtgo** » Tue Nov 08, 2005 11:20 am

yes, it is still correct that I don't have any problems with the GUI (except for occasional disconnects that occur once every couple of days).. In fact, now that several developers are using the command line, they all get the same results, so I would guess that it's a problem specific to your command line code. Maybe you have a short timeout in the communication link (TCP) and it's disconnecting because of that. I would bet you guys don't see the problems because you don't use slow links to test with.

I challenge you to set up a public SOS server with tons of worthless files on it, go home, dial up to the internet, and do a command line update.

I could run a network analyzer (ethereal) and log the output if you know how to read the logs?

The command line logs in for each action, so I believe I am currently logging in each time.

As noted earlier, I don't have to run the script for this to occur. just executing a large get causes the problem. You also have two other customers that reported this problem on your forum and there was no solution posted for them either.

SourceGear Support

soscmd errors

soscmd errors

better, but still not there