Fixing Extremely Slow rsync on OS X

Last night I moved out my photo collection from my MacBook Pro’s internal SSD to a neat little Samsung T1 USB3 SSD. And since Time Machine still can’t handle backing up external drives correctly (it removes the external drive’s contents from the backup when it is not connected), I created a small script to do the backup using the good old rsync.

Backup of the T1 goes to a dedicated AFP share on my FreeBSD server (shared using Netatalk). An Elgato Thunderbolt 2 Dock provides gigabit Ethernet connectivity for the MacBook Pro. I usually see file transfer rates in the 60MB/s – 110 MB/s range from this setup. So the 3MB/s average what rsync produced here was a bit shocking.

And the transfer rate jumped up to the usual range when I downloaded something from the Internet! And went down to 3 megs when the download finished…

It seems that the nine year old version of rsync included in OS X Yosemite can’t handle the OS’s network power management features correctly. When another app wakes up the net to full speed, it works fine, but rsync alone can’t do that.

The solution is embarrassingly simple: install rsync from the ports collection. Did that, updated my script, and presto, I suddenly get transfer speeds in the 50MB/s – 80MB/s range…

  ☕ ☕ ☕

Did this post help you? Consider buying me a coffee if so.

Keeping OS X Display Brightness Unchanged

In the previous installment in my monitor calibration series, I mentioned the need to keep monitor brightness unchanged after calibration – as any change to it invalidates the profile.

But what if I press the brightness control buttons on the Retina MacBook Pro (or on any other MacBook)? Should I immediately re-calibrate and re-profile? Well, there’s a slick trick.

MacBookBrightnessControl2MacBook display brightness is changed by default in whole unit steps using the brightness keys. But holding down Shift + Option while pressing the keys will change it to 1/4 unit steps – the same amount ColorEyes Display Pro (and other software) uses when controlling the display.

What I usually do after calibration and profiling is: increase the brightness by 1/4 unit, take note of the (previous) value, and immediately decrease it back to where the software set it. This way I could return the display to the calibrated state even if I had to change, or accidentally changed its brightness.

Another enemy of keeping the calibration intact is the display dimming preference of OS X – which tells the machine to slightly dim the display while running off of batteries. It might be useful for users not requiring color accuracy and consistency, but turn it off for calibrated displays (by default it’s on).

DisplayDimming2

In the next installment I’ll examine the differences between hardware and software calibration.

ShutterCount Supports the 7D Mark II

I received my Canon EOS 7D Mark II last Thursday. The very first thing I did with the camera was to add it to ShutterCount. Well, this was one of the reasons for buying it.

A first impressions post will also come in a couple of days weeks, but first things first.

7d2-sc

Apple approved the update last night, so the new version (1.3) is now available on the Mac App Store.

The update is free for existing users. New customers can buy the app on the Mac App Store.

ShutterCount for the Mac Released

My newest Mac app, ShutterCount displays the number of shutter actuations (the shutter count) of your Canon EOS digital camera. The shutter count is read directly from a USB-connected camera, and thus provides accurate numbers that are not attainable with simple EXIF-based methods.

ShutterCount

Simple is that. You can skip the trip to Canon for a reading, and you don’t have to pay every single time you want to check the count. Note however, that video clips recorded are not included in the number. For a separate mirror movement reading (that includes videos) you should still have to visit a Canon service center.

Speaking of money, you can grab the app at a special introductory price from the Mac App Store. This promotion runs until the end of October.

Supported cameras are the following:

  • Canon EOS-1D X
  • Canon EOS 5D Mark II
  • Canon EOS 5D Mark III
  • Canon EOS 6D
  • Canon EOS 7D
  • Canon EOS 60D
  • Canon EOS 70D
  • Canon EOS 100D / Rebel SL1 / Kiss X7
  • Canon EOS 600D / Rebel T3i / Kiss X5
  • Canon EOS 650D / Rebel T4i / Kiss X6i
  • Canon EOS 700D / Rebel T5i / Kiss X7i
  • Canon EOS 1100D / Rebel T3 / Kiss X50

hdiutil Requires sudo for Read/Write

Another unwelcome surprise from Apple: in some recent OS X update (I don’t know exactly which one as I ran into the problem this morning) they changed how hdiutil behaves when mounting sparsebundles in read/write mode (it is used in my build scripts as a step toward generating the final setup DMG): it now requires sudo-ing when you use the -readwrite flag.

The problem is that sudo by default prompts for a password and silently fails when used from a script. The solution is to remove that password requirement. This is carried out by adding a line to the /etc/sudoers file:

%admin ALL=(ALL) NOPASSWD: /usr/bin/hdiutil

This innocent one-line edit requires lots of command-line gymnastics, however. Permissions on the sudoers file is 440 by default, and the sudo command fails to work with anything other that that.

So you have to boot your Mac in single user mode to do the edit (by holding down Command+S at startup). Then you have to mount the root file system in read-write mode and change the permissions on the file:

mount -o update /
cd /etc
chmod 640 sudoers
vim sudoers

Add the line to the end of the file, save it and restore the file’s permissions:

chmod 440 sudoers

You can now reboot, and sudo hdiutil will not ask for a password any more! So it can be safely used from within build scripts.

  ☕ ☕ ☕

Did this post help you? Consider buying me a coffee if so.