Odd that this has never bitten me before. I was rsyncing a directory from a Linux box on to an external USB drive with a FAT32 filesystem on it. Every time I reran the sync process some, but not all, of the files kept attempting to resynchronise.

At first I assumed that the issue is with permissions or owners - which aren't supported under the VFAT mapping. But actually it turns out the issue is with timestamps.

--modify-window
   When comparing two timestamps, rsync treats the timestamps as
   being equal if they differ by no more than the modify-window value.
   This is normally 0 (for an exact match), but you may find it useful
   to set this to a large value in some situations.  In particular,
   when transferring to or from an MS Windows FAT filesystem (which
   represents times with a 2-second resolution),  --modify-window=1
   is useful (allowing times to differ by up to 1 second).

Ah hah - it's Microsoft's fault, right? On average half my files are going to have timestamps that are one second out, since FAT only supports a 2-second resolution.

Except that's only true up to a point. While one field of FAT stores the time to a 2-second resolution, another field stores the second to a resolution of one-hundredth of a second.

Now, given Unix timestamps only have a resolution to the second, it would be difficult to preserve existing timestamps exactly. But none of my files have even been near a Windows box yet. You'd expect that linux, when creating files with odd numbers of seconds, would set the "fine" create time (0x0d) to 100 x 10ms, no?

The fact that rsync needs a workaround suggests this isn't the case.

Is this a long term linux bug that people have just been satisifed to create workarounds for, or is there some additional technical issue I'm not seeing?

Update: Actually, it looks like the fine resolution for timestamps is only greater than 2-seconds for the creation timestamp, and not for last modified timestamp.