views:

170

answers:

5

Is it a viable option to compare two FileInfo.CreationTimeUtc.Ticks of two files on two different computers to see which version is newer - or is there a better way?

Do Ticks depend on OS time or are they really physical ticks from some fixed date in the past?

+1  A: 

The aim of a UTC time is that it will be universal - but both computers would have to have synchronized clocks for it to be appropriate to just compare the ticks. For example, if both our computers updated a file at the exact same instant (relativity aside) they could still record different times - it's not like computers tend to come with atomic clocks built-in.

Of course, they can synchronize time with NTP etc to be pretty close to each other. Whether that's good enough for your uses is hard to say without more information. You should also bear in mind the possibility of users deliberately messing with their system clocks - could that cause a problem for your use case?

Jon Skeet
In addition to this answer, I'd point to Eric Lippert's blog post about precision and accuracy of DateTime and system clocks. http://blogs.msdn.com/b/ericlippert/archive/2010/04/08/precision-and-accuracy-of-datetime.aspx. Note the bit about even synchronized clocks being off within a matter of seconds.
Anthony Pegram
A: 

If you are talking about arbitrary files, then the answer about UTC is worth a try. The clocks should be the same.

If you have control over the files and the machines writing to them, I would write a version number at the start of the file. Then you can compare the version number. You would have to look into how to get unique version numbers if two machines write a file independently. To solve this, a version webservice could be implemented which both machines use.

Some file formats have version information built-in, and also time stamps. For example, Microsoft Office formats. You could then use the internal information to decide which was the newest. But you could end up with version conflict on these as well.

Mikael Svenson
A: 

From the way you phrased the question, I assume that for some reason you cannot call the DateTime comparison methods. Assuming this, the msdn page for the ticks property states "A single tick represents one hundred nanoseconds or one ten-millionth of a second. There are 10,000 ticks in a millisecond." Thus the ticks refer to the value assigned by the .NET library and do not depend on the machine/OS(ehich is probably Windows since you are using C#) and can be safely used for comparisons.

apoorv020
+1  A: 

Do Ticks depend on OS time or are they really physical ticks from some fixed date in the past?

Ticks are pretty much independent of the OS. If I remember correctly, 1 second = 10000000 ticks.

So whatever time you are checking, what you get from Ticks is about ten million times what you get from TotalSeconds. (Although it is more accurate than TotalSeconds, obviously.)
A tick is basically the smallest unit of time that you can measure from .NET.

As of speaking about UTC, yes, it is as good as you can get. If the system time on the machine your app is running on is accurate enough, you'll manage with it without issue.

Basically, the more frequent updates there are of the files, the more inaccurate this will be. If someone creates two versions of the file in one second, all of the system times must be precisely synchronized to get a good result.
If you only have different versions once per several minutes, then it is very much good enough for you.

Venemo
+1  A: 

The short answer is that no, this is not a viable solution, at least not in the theoretical, anything-can-happen type of world.

The clock of a computer might be accurate to a billionth of a billionth of a second, but the problem isn't the accuracy, it's whether the clocks of the two computers are synchronized.

Here's an experiment. Look at your watch, then ask a random stranger around you what the time is. If your file was written to on your computer when you looked at the watch, and written to on the computer belonging to the person you're asking 1 second ago, would your comparison determine that your file or his/her file was newer?

Now, your solution might work, assuming that:

  • You're not going to have to compare milli- or nano-second different clock values
  • The clocks of the computers in question are synchronized against some common source ** or at the very least set to be as close to each other as your inaccuracy-criteria allows for

Depending on your requirements, I would seriously look at trying to find a different way of ensuring that you get the right value.

Lasse V. Karlsen