MacOS – does rsync update NTFS directories when the source has not changed

hfs+macosntfsrsync

I'm taking classes with lots of phonetic and grammatical analysis. They've given me an account on a Windows 10 network. Since I am much more comfortable with Mac and Linux (and since the Windows availability hours are limited), I do my work on my Mac laptop.

I auto-mounted my NTFS directories, but there's something flaky with their LAN, so that quite often some apps have read-only access or no access at all.

Consequently, I work in a local copy and frequently rsync changes. But rsync* always updates every NTFS directory—the directory only, never any files (except those I actually changed). Most of those directories, I have never navigated into, yet rsync reports updates all the way down the subdir tree. It's not major—finishes in seconds—but it's still pretty weird.

What do Windows and NTFS do to directories that are never accessed that makes rsync think they have changed?

Best Answer

Allow comparison of mod-times with reduced accuracy

It appears in this type of setup where you mount to an NTFS partition you want to ensure you use appropriate parameters such as --modify-window=5 to increase the default value to allow comparison of mod-times with reduced accuracy.

--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 larger 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).

Further Resources

Related Solutions

Why does rsync nest directories

rsync(1) is picky about the trailing slash. Try this:

rsync -avz /mnt/home/arek/ /home/arek

See the mainpage for all the details.

Update

If one of the paths is mounted via sshfs, I suggest using rsync(1) differently:

rsync -avzP -e ssh username@remotesystem:/home/arek/ /home/arek

(The -e ssh might be redundant at this point; rsync(1) used to default to rsh!)

The -P asks for partial file transfers to be restarted (very helpful on network links that might die) and shows progress (which is helpful over network links, since they are frequently slower than drive-to-drive copies).

Furthermore, rsync(1) is very clever about doing hashing checks on both endpoints when invoked this way -- disk to CPU bandwidth is much better than disk to ssh to network to ssh to wonky filesystem driver bandwidth -- so you will be transferring much less data across the network.

Consider: if you append a single byte to every file, rsync(1) over sshfs will be forced to transfer the contents of every single file from the source to the destination. rsync(1) over ssh(1) will instead start an rsync(1) on the remote endpoint and do the hashing computations on both machines as necessary, and will probably only transfer the last 8192 bytes of every file.

Rsync only files and not directories

I would try this:

rsync -vt /home/Xtian/* /run/media/486D-8336/

This will skip non regular files and enables just the timestamps on files in order to sync only the differences the next time you run it.

From man rsync: -a flag is an alias for -rlptgoD. You can add additional flags if you need to preserve other file attributes.