Porblem: Database1.sos in read-only mode

[Anne]

I'm using SOS Classic 3.5.3 and I can connect to my datasbase fine, but when I try and open a folder or click on a file I'm told that the "database1.sos is in read-only mode and the status information will not be persisted during the session"

I've looked at the file permissions for database1.sos on my system and they are read/write. Any ideas?

Thanks, Anne.

[Guest]

I'm using SOS Classic 3.5.3 and I can connect to my datasbase fine, but when I try and open a folder or click on a file I'm told that the "database1.sos is in read-only mode and the status information will not be persisted during the session"

I've looked at the file permissions for database1.sos on my system and they are read/write. Any ideas?

Thanks, Anne.

[lbauer]

The SourceOffSite Client and Integration DLL both use this file for
persisting local information. When one process needs to update the
file, it places a lock on the file, performs the update, and then unlocks
the file so that it may be updated by other processes. If either the SOS
Client or Integration DLL begin to update the file, and then hang for
some reason, this will prevent other processes from gaining write
access and could lead to this error message.

In any case, when this situation arises, it is best to exit all SOS
processes and restart the client machine. In general, this problem
should only occur in rare instances, so if it continues to happen
frequently for you, then we will need to determine what else may be
going wrong in your environment.

[Guest]

Hello Linda,

This is actually happening all the time with one particular database, and with another database the client actaully crashes when it tried to open it.

I have tried to uninstall the sos client from add/remove programs but it won't install as it complains that it can't find a binary (it doesn't say which one). Makes me think that something may not be registered properly?

Thanks, Anne.

[lbauer]

There may be a problem with the SOS Client cache files, named databaseX.sos. There's a file for each database on each server, and they're in the Servers directory in the SOS Client directory if you're using SOS 3.5.x. You might try deleting these files. Your cache file(s) will be recreated. This will mean downloading the project tree again and resetting working directories.

If you continue to experience this problem, however, it may mean something is corrupting or changing your databaseX.sos files outside of SOS. That would take some investigation on your part to determine how that might be happening.

[Rasputin]

I am having a similar problem with 4.1.0. the databaseX.sos with this version resides under "C:/documentandsettings/[user name]y/applicationdata/sourcesafe/servers/xxx/database1.sos", I believe, and it's coming up with the read-only message. my client was upgraded from 3.5.3 in the following manner:

1) 3.5.3 was uninstalled (directories that could not be removed were left alone, along with whatever files remained)
2) 4.1.0 client was installed into the same directory as 3.5.3

2 or 3 different users reported the problem. all systems in question run the corporate version of Sumantec Norton AntiVirus (I know some programs take exception to it, so mentioning it just in case)

Any ideas?

[lbauer]

Yes, in 4.x, the databaseX.sos files have been moved to the users App Data folder.

Did you try deleting the databaseX.sos file in that location? Do you continue to get the error?

Is it possible that some process has modified this file or put a lock on it? Do you have real time antivirus scanning on the client machine? Does turning it off temporarily make any difference?

[lbauer]

Yes, in 4.x, the databaseX.sos files have been moved to the users App Data folder.

Did you try deleting the databaseX.sos file in that location? Do you continue to get the error?

Is it possible that some process has modified this file or put a lock on it? Do you have real time antivirus scanning on the client machine? Does turning it off temporarily make any difference?

[Rasputin]

About the only thing I did not try was turning off the AV - 1) it's not a real solution, and 2) I can not because the settings are controlled from the corp. server.
There are other issues, too, that have been cropping up. sometimes the client would try to connect, and simply sit there, hung. When that happens, I must re-start the SOS service on the server to be able to log in again. I checked the server log and am getting messages intermittently like these:

1/18/2005 8:36:34 AM - Connection accepted from 10.100.101.11:3596 on local address 10.100.101.12:8081, session id is 9.
1/18/2005 8:36:51 AM - 9: Exception: Index was outside the bounds of the array
..........
1/18/2005 8:34:28 AM - 5: Exception processing messages: Object reference not set to an instance of an object.
..........
1/18/2005 8:33:06 AM - 1: Exception: A blocking operation was interrupted by a call to WSACancelBlockingCall

What is that? I had all my users completely remove the database1.sos and index.sos files from their systems as per instructions in other posts here, but that didn't correct the issue. And it seems the login process hangs 3 or 4 times a day, and when it happens to one user - no one can log in, the server is not responding. Help!

[lbauer]

If the SOS Server is frequently hanging, this KB article can help:

http://support.sourcegear.com/viewtopic.php?t=1866

[Rasputin]

Thank you Linda. I modified the registry as per the KB article, and will post the result of this once my team has had a chance to use it for a day or so