Drop box "Conflicted" files cleanup advice?

[Rdale]

Here is a brief sequence of events to get you up to speed. Likely the first few events are not relevant:

My Macbook Pro Hard drive crashes.
I replace it with a 500G drive I had never installed in a Mac Mini, restore from Time Machine backup
I begin using Drop Box, and have my current project syncing to another computer (but do no even have scrivener installed on that machine)
Some trouble, either with my “new” hard drive, or with corrupted files from the backup causes a lockup. <-- Enter the “Conflicted” dropbox files?
I re-install Snow Leopard from DVD, and go through the fun of re-licensing and re-installing software.

When I open my project in Scrivener for the first time after one of the crashes above (probably the second), I get a message that the project is open on another computer, but I allow it to open it anyway (there is no other computer on which I use Scrivener at the moment).

Recently, I took a peek inside my project package file, and noticed that there were 3 files with “Conflicted” in their names, and then the corresponding original(?) files.
They are:
./Automaton (Jayne’s conflicted copy 2011-02-23).scrivx
./Files/binder (Jayne’s conflicted copy 2011-02-23).autosave
./Files/search (Jayne’s conflicted copy 2011-02-23).indexes
./QuickLook/Thumbnail (Jayne’s conflicted copy 2011-02-23).jpg

So to my questions:

1. Is there any way I can compare the contents of these files with the “originals” to see if the newer ones (my last editing session having been March 8) are missing anything? Is there much of a point in trying?
2. Are there likely other files I should be looking at that aren’t named with the word conflicted in them?
3. Can I just delete these (after making a backup, of course)?
4. Once I have verified that my cleaned up version of the project is good, will Drop Box notice the changes if I just replace the “conflicted” package with the one having those files removed?
5. Because last night I experienced the Hard Drive Click Of Death while trying to copy over a large set of files on this “new” drive, I’ve got another on order. If my computer decides to lock up again before I can clone my current setup to the NEW new drive, how do I prevent Drop Box from getting these “conflicted” files if I’m not even opening the project on any other computers yet?

[AmberV]

This usually happens when a project has been edited by two different computers while one of them was offline. When it goes back online it has a list of changes to upload, but Dropbox notices that these same files have already been altered on the server, and so it produces conflict copies to let you sort it out. In a normal scenario this is obvious, but in Scrivener with everything hidden, it can go completely unnoticed. That might not be precisely what happened in your case; with all of the hardware and crashing problems, it could be another factor, but either way here is how to go about fixing it.

The best way to check is not to try and compare each file individually, but to create two copies of the project in Finder (so you have three total). Name one “Jayne” and the other whatever else you want. In the Jayne one, go with all of the copies labelled likewise by deleting the primary copy and renaming the Jayne copies so they no longer have the parenthetical. In the other project copy, just delete the parenthetical copies.

You asked if anything else should be checked: yes. Just go through every single folder and look for conflicted copies. In some cases (like the Snapshots folder) you’ll find List View in the Finder to be the most useful as you can expand several hundred folders at once and quickly scroll through the list.

Now open both projects side by side in Scrivener. If one malfunctions in any way (produces _Recovered Files in the binder or just flat out refuses to open), then your choice is easy. Stick with the one that doesn’t. Recovered files happen when the binder doesn’t have instructions for files that exist in the project. Say you add a text file to the binder, but then revert back to a copy of the binder that pre-dates that addition, the text file is now an orphan and the binder doesn’t know what to do with it, so it collects it and any other orphans into the recovered files folder in the binder when you open the project.

The second thing to look for is something only your brain can do: look for any structural or meta-data type disparities and figure out which one is the best copy—or the closest to best and then manually merge the changes from the other project into it. You’ll want to do this even if one produces Recovered Files and the other doesn’t. Just remember both of these represent two different “forks” of work. You did something in both of these copies. The trick is remembering and finding what you did. In your case, given the list of conflicted copies you pasted, it’s likely you did make content changes. The search index file has been forked, which makes it likely there are content level conflicts, not just binder structure and meta-data conflicts. So definitely scan through the Files/Docs folder as well. The search index also records binder titles and such, so it doesn’t necessarily mean there are content forks, it just makes it more likely.

The .scrivx file is plain-text human readable XML, so it would be possible to use FileMerge or another diff utility to scan for changes. This would be more of a fact-finding task. I wouldn’t recommend trying to merge the XML files by hand as that requires a lot of omniscience to do correctly. Just use it as a reference for where to look in the two binder copies.

Are there likely other files I should be looking at that aren’t named with the word conflicted in them?

Unlikely. If there isn’t a conflict copy, that means Dropbox was never confused, and that means the content should be identical in both forks.

What do you need to check for are files that don’t exist in one fork. If you added files or folders. If you can’t find a way to integrate the new files back in easily. I would consider just importing them as files into the project you are using as your new master project.

Once I have verified that my cleaned up version of the project is good, will Drop Box notice the changes if I just replace the “conflicted” package with the one having those files removed?

What I would do is this: once you find and/or merge a corrected .scriv copy from one of the duplicates, use it to replace the current one in Dropbox entirely. I’d back the current one up and call it something obvious so you know it was the last backup you made before merging things.

This way if you come across any problems a week or two from now, you’ll have everything you need to salvage the problem in that backup.

…how do I prevent Drop Box from getting these “conflicted” files if I’m not even opening the project on any other computers yet?

Here is your checklist. If you follow that to the letter in all cases, you should avoid this problem entirely. I would add one more to that list, the corollary to #2: wait for Dropbox to finish syncing before sleeping or shutting down the computer.