Strange Pasteboard Behaviour in Lion

For months I’ve been plagued with a frustrating and inconsistent problem: drag & drop and copy/paste randomly decide to stop working in Rapid Weaver, with a cryptic error reported to the system log:

This issue has prevented me from being able to work on adding drag & drop file uploads / downloads to Convoy, and thwarted my attempts to work on secret project.

After fruitless research into the issue, I performed a clean install of Mountain Lion, and my initial testing made me think the issue was solved. Due to circumstances beyond my control, I did not get a chance to work on Convoy or secret project until recently.

The first thing I noticed tonight, when I did finally get started, was that the problem was back. Again, I failed to find a solution online. I considered the times that the broken functionality had worked, and those times that it didn’t. One difference came to mind – when didn’t work, I had opened Rapid Weaver from the terminal. Times I remember everything working; Rapid Weaver had been opened normally. Experimentation proved this. Eureka!

A Delicious Workaround

Finally able to start work, it struck me that I’d be developing without the golden joy that is having console output. I solved this issue by using nohup and tail, and two Terminal tabs tmux panes. To do this, open Rapid Weaver in one tab pane:

$ nohup /Applications/ > RW.log 2>&1

And in the second, follow the logfile:

$ tail -f RW.log

Whatever would normally be output into the first tab pane is written to the log file, and will therefore be displayed in your second tab pane.

Update: after mentioning this issue on Twitter, @passcod noted that this sort of issue may arise when using tmux instead of the basic shell (which I do use). Further experimentation proved him correct, but none of the suggested fixes that I tried from those suggested here: Unable to use pbcopy while in tmux session allowed me to use Rapid Weaver without problems when started from within a tmux session. I use a custom .zshrc file on computers I control, which automatically enters a tmux session when a Terminal opens, so instead of closing my tmux session before opening Rapid Weaver from the Terminal, I will continue to use the workaround described above.

And thus a frustrating issue that has irritated me for too long is wrapped in a workaround. Have you encountered a similar issue? How did you get around it in your situation?

No comments | Trackback