How should I be using rsync with FAT32/VFAT

[John Long]

Thanks a lot, Kevin.

I have a new Linux box and tried to set it to UTC but I think gnome
outsmarted me...

I'll use -rt and maybe ignore timestamps entirely rather than the
window. If I find something wrong on the USB stick I can always copy it
again. I love the -c option, but it takes forever on slow media.

John


On Tue, 2018-01-16 at 13:27 -0500, Kevin Korb via rsync wrote:
> #1 yes, you should use -rt instead of -a as everything else in -a is
> incompatible with vfat.
> 
> #2 timestamps will always be a problem on vfat.  It has a 1 or 2
> second
> resolution so --modify-window=2 is a common solution.  However, if
> you
> live somewhere that has yearly clock changes (we call it daylight
> savings time) those will cause the timestamps to be off by an hour on
> top of the 1-2 second problem.
> 
> The only potential solution I have ever found for #2 is to always run
> rsync in a time zone that does not have clock changes (ie env TZ=UTC
> rsync --modify-window=2 ....)  This way rsync will copy the
> timestamps
> using the same interpretation of what they mean.
> 
> 
> On 01/16/2018 12:48 PM, John Long via rsync wrote:
> > Hi,
> > 
> > I have been using rsync for over ten years. Thank you! It is a
> > great
> > tool.
> > 
> > Recently I had the misfortune to have to use it to sync files to a
> > USB
> > stick that is for a platform that only supports FAT32.
> > 
> > After missing the point a few times and having it copy some of the
> > same
> > directories and files needlessly I saw the timestamps on the source
> > files (in reasonable filesystems like JFS, XFS, etc.) were a few
> > seconds different from those on the VFAT filesystem on the USB
> > check.
> > Looking around the net this is a popular issue with FAT32 and
> > people
> > get around it by ignoring timestamps or by using -rt instead of the
> > usual -a
> > 
> > Do you have recommendations on the best way to keep file trees in
> > sync
> > when one of them is FAT32 and the other is a real filesystem?
> > 
> > Thanks,
> > 
> > John Long
> > 
> > 
> 
>