There's likely little I can add to that unless I want to create a cheatsheet for myself on my own blog.
What I do want to talk about...since it was surprising enough to me that I'm still thinking about it a day later...is an incident where rsync seemed to be running fine, but it was totally $%^& with me to the point where I needed to call in a coworker to rubber duck the issue.
I had two Macintoshes. On MacSource, I had a folder I'll say went to "/Users/myname/files/Town Problems". On MacDestination, I also have a "Users/myname/files/Town Problems" folder.
I used my typical rsync command line that...to my knowledge...had not given me issues. The whole archive and recursion and delete settings with a sprinkle of verbose and progress. It was pretty simple, and since it was a modified version of lines pulled from my quick and dirty sync scripts, it was nothing that should have had trouble.
Only I knew it had trouble when the first few lines scrolling rapidly through my terminal included, I could have sworn, the word "delete."
Huh? Not that many files should be getting deleted on that remote machine, I thought. There should have been two files deleted. Not enough that I should notice it in the rapidly-filled scroll buffer jittering past my eyes.
I secure-shelled into the remote machine and scanned the directory. The files that should have been deleted were still there. And a directory that should have been added, wasn't.
I scanned the command line I used. No typos.
Re-ran rsync with more verbose options. Everything, it swore, checked out and was a match. "Synced!," it seemed to say.
I fiddled with quotes, since there was a space in the name and rsync can be a pain in the arse with properly handling spaces, depending on how (and what) is doing the interpretation of the command on the machines involved. I tried various combinations of escape characters mixed with " and '. Each attempt gave no feedback indicating anything other than a successful sync. I even triple checked the use of a trailing slash on the specification, as common with rsync issues as off-by-one errors in loops for programmers.
"Dammit!"
I called in a coworker to glance at the issue and see if he could see what I was missing. At first, he couldn't. We talked it through as we navigated up and down the directory tree to see if it failed to expand the command line correctly, dumping it into "/Users/myname/files/Town/ instead of Town Problems. "No, that's not it. There's a /Users/myname/files/town directory, but not Town..."
Insert the screeching halt of realization there.
OS X does some really fun things to hide the fact that it's a POSIX UNIX engine hiding behind a pretty interface. And most of the time, it's really good at hiding the UNIX bits to the point of being usable by home users. The rest of the time those tricks create...quirks. And I realized we were running into one of those quirks.
"Dammit!"
diskutil info /
That's a command that gives information about your drives. Here's a couple lines from an example output:
File System Personality: Case-sensitive Journaled HFS+
Name (User Visible): Mac OS Extended (Case-sensitive, Journaled)
...See that "Case-sensitive" bit buried in there? Yeah, that's missing from the drives I was using in the sync. Apple recommends, probably due to compatibility issues with certain software, not to use case-sensitive HFS+ on root partitions. The thing is this is easily forgettable because the bash shell hides this when doing autocompletion. For example...
cd temp
mkdir Test
mkdir test
->mkdir: test: File exists
ls
->Test
cd t<tab>
->autocomplete doesn't do anything
cd T<tab>
->autocomplete changes it to "cd Test/"
<backspace the line>
rmdir test
ls
->
mkdir Test
ls
->Test
cd test
pwd
->/Users/myname/temp/test
cd ..
ls
->Test
Autocomplete treats the folders as case sensitive. Other commands do not. Because bash enforced case sensitivity while the OS didn't.
HAHAHA...the whole time rsync was syncing (and had wiped) my "/Users/myname/files/town" folder and I hadn't had issues with my previous syncs because I wasn't using folders that had shared namespace with partial-string-matched folder names with different capitalization.
How to solve the problem at hand? According to the history file, I used this:
rsync --progress -av --delete '/Users/myname/files/Town Problems/' myname@MacDestination:"/Users/myname/files/Town\ Problems"
...and that interpreted the file paths correctly. With a slight modification, I restored my "town" folder from my backup copy, ending my hour of expletive-filled head scratching.
Once again, bitten by the attempt to make things more user-friendly. Dammit!
No comments:
Post a Comment