incorrect timestamps on Mac Ventura rsync to usb/msdos

[georgalis]

Hello, I suspect this bug is in the new Mac OSX Ventura kernel, but I thought I'd post here for general information and confirmation.

After upgrading to Ventura Mac OS 13.0.0 (and subsequently 13.0.1), rsync no longer maintains correct file modification time on usb/msdos destination files, rather the destination file modification time is set to the transfer time.

This does not generate an error but prevents rsync functionality. For example, if maintaining memory stick with 16GB of data for an IoT device, every invocation of rsync will re-transfer every file.

A workaround is to iteratively set the destination mtime for every source file with touch -r {src} {dest}, after the rsync operation. Subsequent rsync operations will recognize the like timestamps and file sizes and negate transfer. (Don't forget --modify-window=1 required for msdos filesystems!)

I have contacted Apple support, submitted a bug report, and created an Apple discussions thread https://discussions.apple.com/thread/254383328

Apparently, Apple bug, support, and discussion channels have no process or procedure to acknowledge receipt, status or commitment to resolve issues. It is clear I won't be getting feedback beyond, "apply updates."

The issue should be easy to verify and reproduce in both OSX base rsync version 2.6.9 and brew rsync version 3.2.7, some shell commands to demonstrate the anomaly are attached: apple-discussion-254383328.txt

I expect Apple will fix this once there is sufficient customer complaints. However, given the nature of the problem that may be slow coming. I encourage everyone to (login and) select the "Me too" link in the above discussion page and/or otherwise get Apple's attention on this issue.

I'll followup here if/when I have a portable mtime update script and/or a ktrace analysis...

[georgalis]

As mentioned in the apple discussion 254383328, I've confirmed an observation: mode 700 file permissions successfully workaround rsync APFS to VFAT partitions where mode 644 APFS files fail.

I also confirmed the mode 700 workaround does not help rsync transfers to ms-dos partitions.

I have since observed that on regular invocations (when rsync is expected to set the timestamp), subsequent rsync invocations would work 50% of the time, per file. Ie, if 10 files were transferred, approximately five of them would be arbitrarily re-transferred, with every subsequent rsync.

Nevertheless, the procedure of "touch -r" from every src file to every dest file, after every rsync, is effective to prevent re-transfer of unchanged files on the next invocation. It is unnecessary re-touch unchanged files, but the touch operation is lightweight so I just do it every time, to workaround the issue.

[schoeberlt]

Hi @georgalis I have the same issue, very annoying! Trying to copy files to exFAT, rsync is basically useless. However I did not find anyone else with this issue, besides you - how is that possible? Did you find a solution yet?

[georgalis]

create directory structure as needed, followed by touch -r for every destination file prior to every rsync is my workaround (and/or use Linux)

please confirm at https://discussions.apple.com/thread/254383328
and create an apple bug report
and create an apple support request
enough attention and Apple may fix it?

@schoeberlt Why are there not more reports of Ventura users unable to rsync to their microSD (IoT) devices? I am afraid to guess. I certainly hope this does not reflect on the current state of system administration, integration, and workflow optimization.

[georgalis]

It is with sincere consternation that I confirm the problem remains through the Ventura 13.1 upgrade.

[georgalis]

the update Mac OSX 13.2 appears to have fixed the problem.

if you need a workaround for 13.1 or 13.0, this is effective, set src and des (full path) as appropriate.

export src={path} des={path}
rsync -av --delete --modify-window=1 "$src/" "$des/"
( cd "$src/" && find . -type f -exec touch -r \{\} "$des/"\{\} \; )