File Synch problem with timestamp

[rolfk]

---

@jasonhill wrote:
How about an alternate approach?  If the MOD time difference is within a small range (less than 2 seconds, for example) use a MD5 comparison.  If they are the same, the files are the same. If they are different, copy the modified one over.  Not the most elegant solution, but you work with the file system(s) you have.

---

Mmmh, nice idea actually. Though I'm not exactly sure if the MD5 calculation will take much less CPU time than a file copy 😉

You have to transfer the remote file over the network for the calculation of the MD5 and if it turns out to be different you still have to copy the file back. That will result in two entire transfers of the file over the network!

Rolf Kalbermatter

[CoastalMaineBird]

If the MOD time difference is within a small range (less than 2 seconds, for example) use a MD5 comparison.

Well, these files are 20+ meg each, I don't want to read the whole bloody thing just to check the equivalence. That seems like excessive network traffic. Especially since I'm going to be checking them every so often, it doesn't make sense to download them just to find out they're the same as last time.

I can already rely on the fact that (in my case) if the time diference is < 2 seconds, they are the same file.

[CoastalMaineBird]

This call will at some point route through the files system driver that could be a real filesystem or a virutal one like a network. The precision of what this driver does provide is highly implementation specific.

Well, then my question becomes why is the LabVIEW result different from the Windows File Explorer result? If I look with windows explorer, the times are the same (down to the second). But FILE INFO returns times that are different, by one second. I would think that both cases go thru the same drivers to get to the local disk, and the same drivers to get to the server.

Looks like I'm wrong, though.

[CoastalMaineBird]

FWIW, when I change the debugging log to include fractions of seconds (format string = %H:%M:%S.%5U ) decoded from the FILE INFO timestamp, all the times show ".17" on the end except for two, which show ".16".

ALL the ones that fail are different by exactly one second: e.g. 18:09:21.17 vs. 18:09:20.17.

So I don't believe it's some rounding problem.

[Ben]

Hi Coastal Rolf and others,

I use "FileSync" from here

http://www.fileware.com/

As shown in the attached jpg, they include an option to ignore 2 second changes in timestamps.

This "2 second" probably has more to do with the file systems than it has to do with LabVIEW.

Ben

Message Edited by Ben on 05-17-2006 12:47 PM

[CoastalMaineBird]

Hello again, Ben.

Obviously, I'm not the first to run into this problem.

So, if I treat time differences of less than two seconds as zero, then I'm OK.

Maybe the Windows PROPERTIES box is smart(?) enough to do this "disregarding", and the LabVIEW GET FILE INFO thing is reporting the truth, so I get bit.

[Ben]

Coatal wrote,

"... so I get bit. "

I hear you pain. I address this same idea in my Blog entry entitled "The Leaders Lead" found here.

http://forums.lavag.org/blog/champions/index.php?

The nice things about forums like this one is we get a chance to hear about how others have "bloodied their noses" and what trees to watch out for.

Ben

[AmitKaria2k]

Is there any VI in LabVIEW or converion formula which can give me "The UTC time the event was generated as a 64 bit signed integer representing the number of 100-nanosecond intervals since January 1, 1601. This is equivalent to the FILETIME type in Win32 and .Net" ?

Somewhere on NI's website I found that LabVIEW first calculates this time using "SystemTimeToFileTime" VI. Does anyone has a copy or similar VI which can help me?

Pls reply ASAP

[JLS]

Hello,

If that information is exposed through windows, you should be able to make a call to a traditional dll using a call library function node, or to a .NET assembly using the .NET API in LabVIEW.  I'm not sure off the top of my head, but that's something microsoft will probably have documented on msdn.com.

If you do find that windows function, post the name/location (or perhaps your VI which calls it) here - it sounds like it'll be useful to others!  If you find it and have trouble using it in LabVIEW, definitely repost!

Best Regards,

JLS

Message Edited by JLS on 06-02-2006 01:00 PM

[rolfk]

---

@AmitKaria2k wrote:

Is there any VI in LabVIEW or converion formula which can give me "The UTC time the event was generated as a 64 bit signed integer representing the number of 100-nanosecond intervals since January 1, 1601. This is equivalent to the FILETIME type in Win32 and .Net" ?

Somewhere on NI's website I found that LabVIEW first calculates this time using "SystemTimeToFileTime" VI. Does anyone has a copy or similar VI which can help me?

---

I don't have a VI ready but it's not terribly hard to do that at least if you want to convert the LabVIEW timestamp to a FILETIME. If it's about the timer tick (this is basically the number of ms since the timer was initialized at computer boot time) and which is the time value that comes with events in the event structure then there is no exact conversion but at most some sort of approximation.

Basically both a LabVIEW time stamp and Windows FILETIME are UTC based so what you would want to do is to multiply the LabVIEW timestamp with 10'000'000 to get the 100ns resolution, then convert this to a int64 (only supported in LabVIEW 😎 and last but not least add 0x0153b281e0fb4000 to this. In LabVIEW version smaller than 8.0 you would have to do some more arithmetic to perform the integer arithmetic on the two seperate 32bit integers that an int64 consists of.

The according C code for this would look like this:

void TimestampToWinFileTime(const float64 secs, FILETIME *pfileTime)
{
    uInt32 temp;

    pfileTime->dwHighDateTime = (uInt32)(secs * (78125.0 / 33554432.0));
    pfileTime->dwLowDateTime = (uInt32)(secs * 1E7);

    /* Convert to int64 100ns intervals since Jan 1 1601 GMT. */
    temp = pfileTime->dwLowDateTime;
    pfileTime->dwLowDateTime += 0xe0fb4000
    pfileTime->dwHighDateTime += 0x0153b281;
    if (pfileTime->dwLowDateTime < temp)
        pfileTime->dwHighDateTime++;
}

Rolf Kalbermatter