File Synchronization problem with TimeStamp

[CoastalMaineBird]

Win2k, LabVIEW 7.0

I'm trying to do file synchronization between the data files I produced on the local disk, and a remote server. I am doing a LIST FILES on the local folder, and a LIST FILES on the remote folder. For each file, I do a GET FILE INFO, and look at the LAST MOD data (a TIMESTAMP value). For each file in the SOURCE folder, I match it up with the corresponding entry in the DESTINATION folder. I then compare the times, and if the SOURCE timestamp is greater than the DEST timestamp, then I delete the DEST file, and COPY the source file to the DEST.

There are a few files that fail this process, though, and I am puzzled as to why.

If I look (via Windows explorer) at the properties of one of these files, it says the LAST MOD date is 6:09:20. That is the case for BOTH the local copy and the remote copy.

However, the SYNCH logic above insists on copying this file every time it runs. When I add logging stuff to the synch process, it tells me that the local file has a date of 6:09:21, and the remote file has a date of 6:09:20, so it wants to copy it.

But after the copy, things are exactly the same - Windows shows the times identical, but LabVIEW shows them ONE second apart, and copies them AGAIN the next time it runs. This is true for about 6 files out of a folder of 50-60. I suppose I could allow for that one second, if I knew why it was there.

What's biting me here? If the file really had a MOD DATE resolution of 1 mSec say, then I could understand that maybe the PROPERTIES window truncates the value, and the TIMESTAMP does not. But even then, it ought to copy ONCE and set them the same...

The "Server" I am testing on is running OSX, 10.4.6, if that matters.

What am I missing?

[Joris Robijn]

Ah, I think you're fooled by the FAT filesystem that has some bad habits. It will only store up to 2 seconds resolution. So every time you store a file with an uneven number of seconds it will loose the last bit and become even... It also cannot handle time zone changes and stores everything in local time. And it's not a journaling filesystem, so corruption occurs easily. 

Just upgrade to HPFS, ext3, NTFS, HFS+ or any other proper filesystem. I even did that on my USB stick (convert.exe u: /fs:ntfs). Works flawlessly.

Joris

[CoastalMaineBird]

So every time you store a file with an uneven number of seconds it will loose the last bit and become even

That's not the case. If you read the real thread (I'm not sure how this got posted here, though I know I'm responsible), you'll see that I found cases where it rounded(?) the time from an even number to an odd number of seconds.