Wrong modification timestamps when writing files to SMB shares under Windows CE 5.0

If you have ever wondered why sometimes the modification timestamps of files written by a Windows CE 5.0 client to an SMB share on a remote server are in history or future, here is an explanation:

The SMB protocol provides the possibility to set the last write time by the client. But unfortunately, the time must be provided in local server time. But how could the client possibly know the local server time?

While establishing an SMB connection, the local server time and time zone is provided by the server. Windows CE 5.0 seems to determine the time difference between the server time zone and its own time zone on opening the connection. When writing to a file on the SMB share and closing it, the time difference appears to be used to calculate the server local time based on the client local time. But if the time zone is changed either on the client or on the server while the connection exists, the calculation will result in a wrong modification timestamp because the time difference is no longer valid.

As an SMB connection is automatically terminated after a specific time (10 minutes by default) when all resources have been closed, the problem might not be very obvious. If the SMB connection is re-established or after a reboot, the new time difference will result in valid modification timestamps again.

The behavior has been reported to Microsoft and we think there will be a QFE for this issue. So stay tuned and we will keep you informed...