Don't know if what you are experiencing is the same as "here" ... I notice the "local" file (COMPUTER) date gets changed on the remote (PLUG) to the "date" the file was moved to the remote (PLUG). The date has two impacts that are really annoying to me. The first - visually inspecting the local and remote files to determine if an update needs to be done is almost impossible since the dates and times on the remote have been fiddled. The second - local-to-remote is not so bad for a backup since the local file {date}&time will be later than the remote file {date}&time. This is not so good in a remote-to-local scenario. This seems to be what you are also experiencing. The remote {date}&time are always later than the local {date}&time. You, too, indicate an unnecessary churn of unneeded updates because of this date fiddling on the remote.

Maybe if more people would bug support about this they might use the local {date}&time when storing a file on the plug rather than the upload date/time as is being done at present.

BTW, I seriously doubt that what you are experiencing has anything to do with NTFS for FAT32. I would venture a guess that it is a design feature that has unintended consequences especially to those of us that want a reliable and quick backup and restore capability.

Pogoplug Farming(tm) is Fun!

I use SyncBack to meet a similar requirement and am experiencing a similar problem.  I wonder if this is due to the file time/date that is written via the "FAT-abstracting" driver being different than the original source NTFS time/date.  Below is what SyncBack's Help file says on the issue.  I have it set to ignore time difference of <=2s but the problem persists.  It would be nice if this pogoplug driver allowed one to choose whether to use NTFS or FAT or the actual native drive format or what-have-you.

Q: Why don't the files in my destination directory have the correct last modification date & time?

A: Windows has two main filesystems: FAT (including FAT12, FAT16, and FAT32 - FAT = File Allocation Table) and NTFS (New Technology File System, or NT File System). When you format a disk, or partition, you choose which filesystem to format it in. For Windows 95/98/98SE/ME, you can only format using FAT. For Windows NT/2K/XP/2003 you can choose either FAT or NTFS.

There are important details that must be taken into account when copying files between FAT and NTFS filesystems. The most important of these is that the last modification date & time for files in FAT filesystems is accurate only to within 2 seconds. You never get odd-seconds on a FAT partition. For example, the last modification date & time of a file can be 13:00:20 but will never be 13:00:21. On NTFS filesystems it is accurate to within 10 milliseconds. Therefore, when a file is copied from an NTFS filesystem to a FAT filesystem it is extremely likely that the copy on the FAT filesystem will have a different last modification date & time than the original. It will be rounded up to the next even number of seconds. There is nothing any program can do to change this. It is a limitation of the FAT filesystem itself.

When copying files from one NTFS filesystem to another, then the last modification date & times should be identical. However, sometimes, usually when copying over a network, the date & time may be slightly different. You can request that the date & time on the copy be identical, but if Windows itself does not change the time to the one requested, then there is nothing that can be done.

For this reason it is highly recommended that you set your profiles to ignore date & time differences of two seconds or less (this is done by default when creating a new profile).

Another issue is that FAT records times on disk in local time. However, NTFS records times on disk in UTC (GMT). This can cause problems when the local time is changed for daylight savings, i. e. the difference in date & time between files will be one hour or more.