I've bumped into a problem using the 4.1.0 version of the client. On the server I have files with modification date 01/06/2005 15:06 and the 3.5 version as well as the windows 4.1.0 client return this value correctly.
However, when I view the remote date on the linux 4.1.0 client, it shows 11/30/2004 15:06. All files that have a remote date beyond 11/30/2004 also show this date even if the time of day is correct. When I check out a file and modify it and then try to check it in again I get a operation failed and the following message in the server log:
1/6/2005 3:15:31 PM - 4: Enter Checkin()
1/6/2005 3:15:31 PM - 4: Ignore remote dates = False
1/6/2005 3:15:31 PM - Exception in CalendarFromDateString(): Specified argument was out of the range of valid values.
Parameter name: Year, Month, and Day parameters describe an unrepresentable DateTime.
1/6/2005 3:15:31 PM - 4: Exception: Specified argument was out of the range of valid values.
Parameter name: Not a valid Win32 FileTime.
1/6/2005 3:15:31 PM - 4: Error processing client request: at System.DateTime.ToFileTimeUtc()
at System.IO.File.SetLastWriteTimeUtc(String path, DateTime lastWriteTimeUtc)
at ClassicService.Client.Checkin(ProtocolMessage messageIn, ProtocolMessage messageOut)
at ClassicService.Client.ProcessMessage(ProtocolMessage messageIn, ProtocolMessage messageOut)
at ClassicService.Client.GetMessage()
Apparently something goes wrong with the timestamps in the linux client. Currently I have to revert to 3.5 version of the client to get the files checked in
Failure to check in files due to file date
Moderator: SourceGear
This is a known issue that was recently reported by another user. Apparently, the Unix client is passing a date to the server that is one month earlier than the actual date. This has been in the 4.x client since last year, but only caused a checkin problem on a few dates -- for instance 7/31 would have been sent as 6/31, which doesn't exist.
The reason more users are encountering this now is that January -- 01 is being sent as 00, which also does not exist. We have new builds that fix this bug and we will post them to the web site later today.
The reason more users are encountering this now is that January -- 01 is being sent as 00, which also does not exist. We have new builds that fix this bug and we will post them to the web site later today.
Linda Bauer
SourceGear
Technical Support Manager
SourceGear
Technical Support Manager
The new builds for SOS Unix clients are on the web site downloads page:
http://www.sourcegear.com/sos/downloads.html
These are version 4.1.1, though we're not stating this on the downloads page.
http://www.sourcegear.com/sos/downloads.html
These are version 4.1.1, though we're not stating this on the downloads page.
Linda Bauer
SourceGear
Technical Support Manager
SourceGear
Technical Support Manager
incorrect remote date in 4.1.1 linux client
I upgraded to 4.1.1 to fix the january problem with checkins. Now all the dates in the remote date column are wrong, although if I view properties for a file the correct checkin date is shown. For example, I checked in a file today - 1/21/05, the remote date column shows 12/2/04 in my Linux client but it is correct in my Windows client.