Finding Dropbox ‘conflicted copy’ files automatically

Dropbox is a great tool, but if you use it on more than one computer, you are bound to find conflicted copies eventually. A conflicted copy is created when the same file is edited on two different computers at the same time, or close enough that Dropbox cannot tell which one is the newest.

The good news is that Dropbox creates these conflicted copies instead of trying to guess which file is the one that you want. The bad news is that if you don’t notice that Dropbox has created a “conflicted copy, you might start using the wrong file. Unfortunately Dropbox does not alert you when a conflicted copy is created, you have to search for it yourself.

Here is an example of a conflicted file: Settings (TJ Luoma’s conflicted copy 2013-01-09).textexpander As you can probably guess, the original filename is Settings.textexpander and Dropbox has added the words “conflicted copy” and the date in parentheses, as well as the username. (The username can be helpful if you find a conflict in a shared folder.)

Doing it is easy, remembering to do it is hard.

I’ve known that Dropbox creates these files for years, but do I ever remember to look for them? Nope. In fact, I don’t even try to remember to look for them. Instead, I have a shell script which does that for me.

The shell script runs every five minutes via launchd, and if it finds any conflicts, it alerts me using Growl and growlnotify. It uses a “sticky” notification in Growl, which means that it will not go away until I click on it (but the notification also has a unique ID so only one notification will ever appear on-screen at any given time).

Installation

  1. Download dropbox-launchd-conflicted-copy.sh to /usr/local/bin/ and make sure it’s executable (chmod 755 /usr/local/bin/dropbox-launchd-conflicted-copy.sh).
  2. Move com.tjluoma.check-for-dropbox-conflicted-copies.plist to ~/Library/LaunchAgents/ and then either 1) run this line in Terminal:

launchctl load ~/Library/LaunchAgents/com.tjluoma.check-for-dropbox-conflicted-copies.plist

or 2) log out and back in.

How do you find the conflicts once you know that they exist?

There are two options that you can use once you are alerted that there are conflicts in your Dropbox. The first is Spotlight, the second is dropbox-launchd-conflicted-copy.sh.

Option A) Use Spotlight. Create a search which looks for filenames that match “‘s conflicted copy”. Actually, you don’t even have to make one; you can just download this one DropboxConflicted.savedSearch and move it to ~/Library/Saved Searches/. You might even want to add that to the Finder’s sidebar.

Note: Once the Saved Search is there, you can even use it with mdfind in Terminal:

mdfind -s 'DropboxConflicted' -onlyin "$HOME/Dropbox"

Or, if you don’t have a saved search, you can use Spotlight on the command line like this:

mdfind -name "'s conflicted copy" -onlyin ~/Dropbox

Option B) Use find. Call me an old crotchety Unix nerd (pause), but I still prefer the Unix find command instead of Spotlight. Asking Spotlight to look for something is like asking my 10 year old: if he comes back and says that he couldn’t find it, I always wonder how hard he really looked. On the other hand:

find ~/Dropbox/ -path "*(*'s conflicted copy [0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]*" -print

This always gives me reliable results, and it only takes a few seconds.

But wait, there’s more! The dropbox-launchd-conflicted-copy.sh script is “context aware.” When it runs via launchd it gives you the Growl notification shown above, but if it on the command line, it will present you with a list of all of the conflicted files that it found. Just launch Terminal.app, type dropbox-launchd-conflicted-copy.sh and press enter. If you don’t have any conflicted files, it will say “No conflicts found” and you can rely on launchd to keep an eye on it in the future.

Finding Dropbox ‘conflicted copy’ files automatically originally appeared on TUAW – The Unofficial Apple Weblog on Wed, 20 Feb 2013 08:00:00 EST. Please see our terms for use of feeds.

Source | Permalink | Email this | Comments

from TUAW – The Unofficial Apple Weblog http://www.tuaw.com/2013/02/20/finding-dropbox-conflicted-copy-files-automatically/

The curious case of the persistent image

The case of the persistent image

The other day I was working on some blog posts, and when I pulled up an image in Preview to edit it, I noticed something odd. It looked like the Preview window was transparent, and that I was seeing a window through it. I thought nothing of it until a few minutes later when I closed a number of open windows on my new 27-inch iMac and noticed that a faint “echo” of those windows was visible on my desktop photo. I realized I was seeing some image persistence.

This is nothing new; back in the days of PCs with cathode-ray tube monitors, it was quite common to see the C: prompt burned into some screens, visible even when the monitor was turned off! But this was a bit of a surprise, since I hadn’t experienced image persistence for a long time. And on a brand new 27-inch iMac? Ouch.

I’m guessing that something kept my iMac display from going to sleep, resulting in the “burn in.” I usually have the display set to go completely dark after 15 minutes, and had never seen this happen before on this or my previous 27-inch iMac.

Immediately I went to the Apple support communities and searched for image persistence and image retention, and I found that this has been a fairly common issue with the new devices. Not only are iMacs prone to persistent images, but some MacBooks are also seeing the problem. (Mike Rose experienced the image persistence issue specific to the MacBook Pro Retina models with LG panels, and ended up having his screen replaced.) There are a number of people who were so concerned that they brought their devices back to the Apple Store and asked for a replacement, but Apple believes that the problem is common to IPS (in-plane switching) LCD panels and not a real issue.

Apple recommends doing exactly what I had been doing — setting display sleep after 15 minutes of non-use. Fortunately, they also have instructions on what to do if your get a burned-in image despite using display sleep. In knowledge base article HT5455, “Avoiding image persistence on Apple displays,” there’s a section on using a screen saver to eliminate a persistent image:

  1. From the Apple () menu, choose System Preferences, and then click “Desktop & Screen Saver.”
  2. Click the Screen Saver tab.
  3. Choose a screen saver.
  4. Set the “Start screen saver” time to be shorter than the “Display sleep” and “Computer sleep” settings in the Energy Saver pane of System Preferences.
  5. To clear the persistent image, allow the screen saver to run for approximately as long as the image was being displayed.

I had no idea how long the image had been “stuck” on my screen, so I just decided to change the screen saver time to five minutes and the display sleep time to three hours and let the “Flurry” screen saver run for that length of time.

Sure enough, once I returned to my iMac this morning, the annoying persistent images were nowhere to be found. One commenter in the support community suggests that this might be a problem with all IPS LCD panels made by LG, and that this didn’t happen with display panels made by Samsung — a company that Apple seems to want to avoid at this time due to the lawsuit situation going on.

Regardless of the cause, it’s refreshing to know that there is a way to correct it and that this does not cause permanent damage to the display. I’ve changed my iMac settings to go to screen saver after five minutes and to display sleep after 15 minutes, and hopefully I’ll never see those persistent images again.

Have any TUAW readers experienced this problem? Did running the screen saver work to eliminate the ghosted images? Let us know in the comments.

The curious case of the persistent image originally appeared on TUAW – The Unofficial Apple Weblog on Mon, 18 Feb 2013 13:00:00 EST. Please see our terms for use of feeds.

Source | Permalink | Email this | Comments

from TUAW – The Unofficial Apple Weblog http://www.tuaw.com/2013/02/18/the-curious-case-of-the-persistent-image/