0

I am developing client-server application based on .NET. Server side runs on Windows XP, client side runs on Windows CE device (Motorola Symbol 3100, this might be relevant).

Client side needs auto-update feature, that I decided to implement on my own due to several topics prevented me from using any ready-to-use auto-update solutions. My application checks for updates every time it starts, comparing files on remote site by LastModificationTime. If there are any, it downloads files from a remote server to temp dir, then it stops and runs another application that replaces updated files and runs main application.

Files are being downloaded through socket, thus after file has been downloaded, my application sets LastModificationTime on every file to the value remote site had provided. I am using a time change solution from this topic, and it works well, i.e. file modification time is updated perfectly well, though comparison fails for some of these files. It may be relevant, that those files for which my solution fails to compare, are Motorola Symbol DLLs.

The problem is that despite all my work, those Symbol files have different modifiction timestamp every time I compare them. It is always differs by 1 hour. E.g. remote site says that file time is 1/24/2012 5:13:08, while on my application side it is 1/24/2012 6:13:08. There are no problems at all with ANY other file. Those "any" are my application exe, my DLLs, DLLs provided by third party components (like OpenNETCF), MS .NET related files and so on. Neither of them troubles me - if they are updated, this is only one time, then no updates if they were not changed really. During compare I always use ToUniversalTime() so that no timezone related differencies occur (and, as I mentioned, this works for other files). So I always get situation like this:

  • remote site provides a number of files, and there are really changed files within it (my application, my DLLs, etc) along with those Symbol DLLs (always!)
  • files are downloaded and updated
  • my application runs again and checks for updates again
  • now only Symbol DLLs are reported as changed
  • application falls into an endless loop, as Symbol DLLs are always have modification time different by 1 hour

I tried to create an additional application that reads file timestamp on Symbol files, then sets it again. I thought that original Symbol files could have some "wrong" datetime or something. This didn't give any improvement, even when I set new time increased by 1 second: during compare in update code it is again 1 hour difference.

Finally, I have decided to remove those Symbol files from my updates. They are not changed frequently, so I have some time to discover on this problem, yet if Motorola will roll out next update - I will fall in my problem again.

I don't know where the problem source lays and I would be grateful for any tip on this. I think my source is irrelevant as this problem occurs just for some files, and anyway modification time is always changed correctly: I checked it on my device, in the server deployment folder (from where updates are being downloaded), everywhere. May be this is timezone-related problem, but how it affects only some files, not everyone of them?

I will explain further. My server in its updates folder contains exactly following files:

FliteDevice.dll

fliteDLL.dll

OpenNETCF.dll

OpenNETCF.AppSettings.dll

OpenNETCF.Configuration.dll

pdt.exe

PdtComm.dll

Symbol.dll

Symbol.xml

Symbol.Audio.dll

Symbol.Audio.xml

Symbol.Barcode2.dll

Symbol.Barcode2.xml

Symbol.StandardForms.dll

Symbol.StandardForms.xml

System.Data.OracleClient.dll

System.EnterpriseServices.dll

System.EnterpriseServices.Wrapper.dll

System.Transactions.dll

System.Web.dll

update.exe

Considering it is first time I'm running an update, my server sends all of these files to client. My client (pdt.exe) receives them all, runs update.exe (and exists so updater could replace app files with newer ones) which replaces changed files (all files in this first-run case).

Then updater runs my application (pdt.exe), and my application again checks its files with those on server side. And now files to update are:

Symbol.dll

Symbol.xml

Symbol.Audio.dll

Symbol.Audio.xml

Symbol.Barcode2.dll

Symbol.Barcode2.xml

Symbol.StandardForms.dll

Symbol.StandardForms.xml

And again updater replaces files, and again it runs main application. And yet again the same files (those Symbol.*) are considered as changed and downloaded and replaced. Only those, no other file exists in further update check request. Never. Something is wrong with exactly those files, not my code, nor other files.

Community
  • 1
  • 1
Camper
  • 145
  • 1
  • 7
  • Somebody is using local time and not dealing with Daylight Savings Time properly. Possibly the remote system. – Hans Passant Oct 24 '12 at 20:02
  • Possibly add a secondary check on MD5 hash. Better than and endless loop. – paparazzo Oct 24 '12 at 20:08
  • @Hans Passant - this might be an option if it'd occur with other files. Still it regards only some of them. Why not others? – Camper Oct 24 '12 at 21:06
  • @Blam : interesting option, but I'm dealing with WinCE device. Additional checks like computing MD5 on 6Mb files would be too heavy EACH time application starts. I don't want to bother my users with such delays, comparing dates is enough for my purposes... – Camper Oct 24 '12 at 21:09
  • I have updated my question with listing of files to be more specific – Camper Oct 24 '12 at 21:32
  • 1
    But comparing dates is not enough if it is not working? Did you actually test hash on 40 each 6 mb files before concluding it is heavy delay. – paparazzo Oct 24 '12 at 21:43
  • I agree with Blam, and furthermore if you test and find that calculating the hash would cause that much delay, I'd calculate them once on the server, store the hashes on the client, then during update just send the hashes to the server, which can then compare the values to the current hash values and send the appropriate files (and updated hashes) back to the client. – Matt Winckler Oct 24 '12 at 22:15
  • Ok, got it. I will try and test. This will take time, and after I finish - I will post my results here – Camper Oct 24 '12 at 22:24
  • Calculating MD5 did do a considarable delay, though it is still reasonable. It's like 3 seconds against like 0.2 seconds on datetime compare. I feel this solution permissable. @Blam if you post a full reply I will mark it as acceptable. Though I still interested why those files were acting this strange way... – Camper Oct 25 '12 at 00:20

1 Answers1

0

Add a secondary check on MD5 hash. Better than an endless loop.

paparazzo
  • 44,497
  • 23
  • 105
  • 176