![]() ![]() # In /etc/zprofile it says to add customizations to ~/.zprofile instead, so this is where our Homebrew's rsync v3.2.3 can overshadow Apple's v2.6.9 in the PATHĮcho "export PATH=/Users/mac/homebrew/bin:$PATH" > ~/.zprofile I've distilled my research into two comment lines just before the actual fix for zsh: # In it mentions /etc/zprofile (different from my pre-existing ~/.zshenv and ~/.zshrc) ![]() I had been putting off the Homebrew PATH issue for a while due to my unfamiliarity with the default zsh on macOS, but this time, I decided I was going to properly research how zsh differs from the more familiar bash, so I could fix the PATH issue the correct way, rather than cargo-cult magical incantations from the Internet. Version 2.6.9 of rsync at /usr/bin/rsync was getting found first in my PATH instead of v3.2.3 that I had just installed to ~/homebrew/bin/rsync. There was a slight problem though, because of how my Homebrew installation was setup to put all binaries under ~/homebrew/bin. ![]() The fix was fairly easy–I had to update the dated v2.6.9 copy of rsync on macOS to match v3.2.3 on Windows. ![]() This is free software, and youĪre welcome to redistribute it under certain conditions. Inplace, IPv6, 64-bit system inums, 64-bit internal inums On the sending machine (Windows) I had rsync v3.2.3, while on the receiving machine (macOS) I had rsync v2.6.9 installed: rsync -versionĬopyright (C) 1996-2006 by Andrew Tridgell, Wayne Davison, and others.Ĭapabilities: 64-bit files, socketpairs, hard links, symlinks, batchfiles, Rsync error: error in rsync protocol data\ AppleInternal/BuildRoot/Library/Caches//\ Rsync error: error in rsync protocol data stream (code 12) at \ BuildRoot/Library/Caches//Sources/rsync/\ Rsync error: timeout in data send/receive (code 30) at /AppleInternal\ Just to be sure, I went ahead to re-read the error output much more closely: The first result on Google: Unable to rsync due to broken pipe turned out to be especially useful in pointing me towards the underlying issue–it turned out I was using two different versions of rsync. The difference here was that Windows was the source and not the destination of the large file transfer, so I decided to search for the first error message in the output "rsync: write error: Broken pipe (32)". I've experienced a similar kind of error a long time ago while transferring a large file to FAT-based filesystem used by Windows, so my first thought was that this was also a filesystem limitation issue. So, after 3 attempts, the transfer fails at exactly 54% of the way during the transfer of an 18GB file. Here's the output from the 3rd try: 65 files to consider Here's the output from the 2nd try: 65 files to consider I scanned the error message and figured it might have been due to a minor network issue, so I re-attempted the transfer two more times and the error was fairly reproducible. Rsync error: error in rsync protocol data stream (code 12) at io.c(823) Rsync error: error in rsync protocol data stream (code 12) at /AppleInternal/BuildRoot/Library/Caches//Sources/rsync/rsync-54.120.1/rsync/io.c(453) Rsync: connection unexpectedly closed (1747 bytes received so far) Rsync error: timeout in data send/receive (code 30) at /AppleInternal/BuildRoot/Library/Caches//Sources/rsync/rsync-54.120.1/rsync/io.c(164) VirtualBox/Ubuntu 18.04 LTS Upwork/Ubuntu 18.04 LTS.vdi vdi file used by one of my VirtualBox VMs: bash -c "rsync -avzh -P -remove-source-files -stats -timeout=60 VirtualBox Password: The transfer went smoothly for the most part, until rsync got to an ~18GB. This article is the concluding part that delves into the issues I encountered on the macOS side of the transfer. I already wrote about my experience using rsync for the first time on Windows. I recently had to transfer large files on Windows to macOS Catalina (10.15.7) using rsync, but I met a few snags on the way. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |