SOS 4.2 always forgets the working folders

toast · Post by **toast** » Thu Jan 24, 2008 2:19 am

Hi!

SOS 4.2 with Linux Suse 10.2 and KDE 3.5

The problem:

I set a working-folder to a project, that works.
I check out files, that works too,
Not checked out files (get latest version) can not be set readonly
The remote-date always is "01/01/1970 00:59"

Then i close SOS and open it again.

-> No working folder is set and all my previously checked out files are labeled as "unknown", local version is empty

regards,

Post by **jclausius** » Thu Jan 24, 2008 2:23 pm

SourceOffSite is going to store the information in your ~/.sos/servers/<server_name>/database1.sos file.

If you close down the SOS GUI client, and grep this file for working folders you should see the setting within there.

Could something be stopping you from creating the .sos directory structure or the files required by the SOS client?

Post by **jclausius** » Thu Jan 24, 2008 2:24 pm

Also, if you log into the SOS Demo server (sos.sourceoffsite.com:8888) and log in (user "donald", pwd "duck"), can you see the tree, and do the remote dates show up correctly?

toast · Post by **toast** » Fri Jan 25, 2008 8:17 am

jclausius wrote:Also, if you log into the SOS Demo server (sos.sourceoffsite.com:8888) and log in (user "donald", pwd "duck"), can you see the tree, and do the remote dates show up correctly?

Hello!

Thank you for your fast reply.
The ~/.sos/server..... folder and the files exist and seam to have sane content (including states for files and the correct working-folder)
If i reconnect to our VSS, the databasefiles get overwritten with "empty" states and folders. The bare vss-structure however is in there.

I could not try your server yet, i have to talk t oour admins to open that port in our firewall.

reagards,

Post by **jclausius** » Fri Jan 25, 2008 10:17 am

I have no idea why the file would be overwritten.

Is this something that happens when launching the sos binary? I've never heard of it doing something like this.

toast · Post by **toast** » Mon Jan 28, 2008 2:09 am

jclausius wrote:I have no idea why the file would be overwritten.

Is this something that happens when launching the sos binary? I've never heard of it doing something like this.

This is even happening if i have SOS running and connect to the server: The database1.sos gets deleted and then grows during "downloading project tree - this may be a lengthy process".
The index.sos grows every time i connect to the vss and repeatingly just contains "database1.sos" and "D:\sourcesave\srcsave.ini"
May there be a issue with our sos-vss-service?

regards,

toast · Post by **toast** » Mon Jan 28, 2008 5:49 am

jclausius wrote:I have no idea why the file would be overwritten.

Is this something that happens when launching the sos binary? I've never heard of it doing something like this.

Ok, i tried your server. There it works fine, no lost folders or states.

There it says after logging in: "Updating file list $/" and then "Updateing file list for <every project with folder>".

On our server only the first "Updating file list $/" appears.

regards,

Post by **jclausius** » Mon Jan 28, 2008 9:39 am

It is possible there is something in the communications that is causing SOS client to have problems.

What do you know about your SOS Server? What version is installed? If SOS 4.x, what version of the .NET runtime is installed? What version of the VSS Automation component is installed - http://support.sourcegear.com/viewtopic.php?t=1510?

toast · Post by **toast** » Mon Jan 28, 2008 10:24 am

jclausius wrote:It is possible there is something in the communications that is causing SOS client to have problems.

What do you know about your SOS Server? What version is installed? If SOS 4.x, what version of the .NET runtime is installed? What version of the VSS Automation component is installed - http://support.sourcegear.com/viewtopic.php?t=1510?

It's SOS 4.2, VSS 6.0, Win 2003 Standard SP2, ssapi.dll 8.050727.42, .NET 2.0 LanguagePack de .Net 3.0

regards,

lbauer · Post by **lbauer** » Mon Jan 28, 2008 4:22 pm

What is the language version of the VSS automation component?

To determine which version of the SourceSafe Automation Component (ssapi.dll) is used by SOS Server, look under this registry key:

HKEY_CLASSES_ROOT\CLSID\{783CD4E4-9D54-11CF-B8EE-00608CC9A71F}\InprocServer32

The value will have the path to the specific ssapi.dll file used by SOS Server. For the version information, locate the ssapi.dll file. Right click on the ssapi.dll file, choose Properties->Version->Other Version Information->Language.

Our public SOS server uses the English version.

toast · Post by **toast** » Tue Jan 29, 2008 1:37 am

lbauer wrote:What is the language version of the VSS automation component?

Our public SOS server uses the English version.

Our's also the English(USA) Version.

regards,

I recognized that on the VSS-Server inside SOS's temp-folder, there only exists one empty folder <vss-username+long number>, that number changes every time i log in with sos.

All checked out paths from sos, shown in the real vss-client, do not exist in the sos temp-path.
Could that be some rights-problem of the sos-server?

(The harddisk has enough free space

)

regards,

lbauer · Post by **lbauer** » Wed Jan 30, 2008 2:06 pm

I recognized that on the VSS-Server inside SOS's temp-folder, there only exists one empty folder <vss-username+long number>, that number changes every time i log in with sos.

All checked out paths from sos, shown in the real vss-client, do not exist in the sos temp-path.
Could that be some rights-problem of the sos-server?

This is expected behavior. The SOS Server uses its Temp directory to create a folder for every logged in user. This is technically the "working directory" for the SOS Server, but files are only there for an instant to confirm all the data is there, then the files go to the VSS database.

It's still not clear why your local client cache is getting overwritten.

Could you enable verbose logging for your SOS Server

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

Then reproduce the problem? Send a copy of the log to support@sourcegear.com ATTN: Linda

Let me know what time in the log you logged in, and what you machine name or IP is in the log.

Perhaps there are some clues in your SOS Server log.