SOS 4.1 on client and server.
We cannot share anywhere on the tree.
Ran Analyze this afternoon:
Analyze Visual SourceSafe Version 6.0d (Build 9848)
Database analysis in progress @ 7/28/05; 4:06p.
Analysis complete @ 7/28/05;10:03p
No errors or inconsistencies found.
Personally, it seems like it might be more fruitful to move to an alternative solution rather than spend time QAing your product.
How to Share set of files in a sub-folder?
Moderator: SourceGear
It's difficult to determine the problem when we can't reproduce the behavior. It appears to be something specific about your environment or database structure.
In these cases, we ask for an archive of your VSS database, or at least the portion of the tree that is experiencing the problem, so we can debug it here. Contact linda at SourceGear.com so we can work out the details.
In these cases, we ask for an archive of your VSS database, or at least the portion of the tree that is experiencing the problem, so we can debug it here. Contact linda at SourceGear.com so we can work out the details.
Linda Bauer
SourceGear
Technical Support Manager
SourceGear
Technical Support Manager
We got the same error, with all the symptoms described by previous users.
Client & Server version: 4.1.2
Here some excerpts from log file:
12/15/2005 9:25:36 AM - Server Information
12/15/2005 9:25:36 AM - Operating System: Microsoft Windows 2000 Advanced Server
12/15/2005 9:25:36 AM - Service Pack: 4.0
12/15/2005 9:25:36 AM - OS Version: 5.0.2195
12/15/2005 9:25:36 AM - Locale: Ox0409
12/15/2005 9:25:36 AM - OSLanguage: 1033
12/15/2005 9:25:36 AM - Total Physical Memory: 511.52 MB
12/15/2005 9:25:36 AM - Time Zone: (GMT+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna
12/15/2005 9:25:36 AM -
12/15/2005 9:25:36 AM - SSAPI.dll Information:
12/15/2005 9:25:36 AM - Location: file:///C:/Program Files/SourceOffSite Server/Interop.SourceSafeTypeLib.DLL
12/15/2005 9:25:36 AM - DisplayName: Interop.SourceSafeTypeLib, Version=5.1.0.0, Culture=neutral, PublicKeyToken=null
.........
12/15/2005 9:49:03 AM - 4: Exception: An existing connection was forcibly closed by the remote host
12/15/2005 9:49:03 AM - 4: Error removing user temp folder 'C:\Program Files\SourceOffSite Server\temp\r.granato632702359417734375'.
12/15/2005 9:49:03 AM - The process cannot access the file "list.h.z" because it is being used by another process.
12/15/2005 9:49:03 AM - Connection accepted from 192.168.10.204:3137 on local address 192.168.10.12:8888, session id is 6.
12/15/2005 9:52:21 AM - 6: Exception: An existing connection was forcibly closed by the remote host
12/15/2005 9:52:21 AM - 6: Error removing user temp folder 'C:\Program Files\SourceOffSite Server\temp\r.granato632702369439609375'.
12/15/2005 9:52:21 AM - The process cannot access the file "makedep_u.z" because it is being used by another process.
You can see the .z added to the file names: I think SOS Server compresses the files when the Client requests data compression during transfers.
I sniffed the sharing operation with Ethereal finding the TCP connection reset by the Client because the Server sends a window full and fails to recover the transmission...
So I made a try:
uncheck the option "General/Use compression for data transfers"
and ta-dah! it works...
Were is the bug?
I hope this can help so you can help us...
Client & Server version: 4.1.2
Here some excerpts from log file:
12/15/2005 9:25:36 AM - Server Information
12/15/2005 9:25:36 AM - Operating System: Microsoft Windows 2000 Advanced Server
12/15/2005 9:25:36 AM - Service Pack: 4.0
12/15/2005 9:25:36 AM - OS Version: 5.0.2195
12/15/2005 9:25:36 AM - Locale: Ox0409
12/15/2005 9:25:36 AM - OSLanguage: 1033
12/15/2005 9:25:36 AM - Total Physical Memory: 511.52 MB
12/15/2005 9:25:36 AM - Time Zone: (GMT+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna
12/15/2005 9:25:36 AM -
12/15/2005 9:25:36 AM - SSAPI.dll Information:
12/15/2005 9:25:36 AM - Location: file:///C:/Program Files/SourceOffSite Server/Interop.SourceSafeTypeLib.DLL
12/15/2005 9:25:36 AM - DisplayName: Interop.SourceSafeTypeLib, Version=5.1.0.0, Culture=neutral, PublicKeyToken=null
.........
12/15/2005 9:49:03 AM - 4: Exception: An existing connection was forcibly closed by the remote host
12/15/2005 9:49:03 AM - 4: Error removing user temp folder 'C:\Program Files\SourceOffSite Server\temp\r.granato632702359417734375'.
12/15/2005 9:49:03 AM - The process cannot access the file "list.h.z" because it is being used by another process.
12/15/2005 9:49:03 AM - Connection accepted from 192.168.10.204:3137 on local address 192.168.10.12:8888, session id is 6.
12/15/2005 9:52:21 AM - 6: Exception: An existing connection was forcibly closed by the remote host
12/15/2005 9:52:21 AM - 6: Error removing user temp folder 'C:\Program Files\SourceOffSite Server\temp\r.granato632702369439609375'.
12/15/2005 9:52:21 AM - The process cannot access the file "makedep_u.z" because it is being used by another process.
You can see the .z added to the file names: I think SOS Server compresses the files when the Client requests data compression during transfers.
I sniffed the sharing operation with Ethereal finding the TCP connection reset by the Client because the Server sends a window full and fails to recover the transmission...
So I made a try:
uncheck the option "General/Use compression for data transfers"
and ta-dah! it works...
Were is the bug?
I hope this can help so you can help us...