gistfile1.txt

2015-11-21 15:08:34,190 +0100 WARNING pid=45155 4641013760:Worker-1        downloads.pyo:481 Detected unsynced changes in /Users/peterbraden/Google Drive/Photos when applying DOWNLOAD-DELETE: [u'/Users/peterbraden/Google Drive/Photos/photos/2014/2014-08-09/DSCF9905.JPG', u'/Users/peterbraden/Google Drive/Photos/photos/2015/2015-07-02/DSCF7303.dng']
2015-11-21 15:08:34,190 +0100 ERROR pid=45155 4641013760:Worker-1        workers.pyo:213 Exception while processing change [ImmutableChange(Direction.DOWNLOAD, Action.DELETE, ino=6770201, name=u'Photos', rid=0B4BhBBbuWQqARE9aamNOQ3U0a1k, parent_ino=1590463, is_folder=True, is_cancelled=False, is_priority=False, doc_type=DocType.FOLDER, hash=-2213610710502213993, _constructor_called=True)]
LocalDownloadDeleteConflict: LocalDownloadDeleteConflict: u'Unsynced files within /Users/peterbraden/Google Drive/Photos', recovery plan: RecoveryPlan.UNKNOWN, recovery targets: set([])
More info: Traceback (most recent call last):
  File "common/workers.pyo", line 186, in Process
  File "common/persistence/sqlite.pyo", line 127, in Wrapper
  File "common/workers.pyo", line 303, in _ProcessChanges
  File "common/worker/downloads.pyo", line 419, in Execute
  File "common/worker/downloads.pyo", line 483, in _DownloadDeleteFromFolder
LocalDownloadDeleteConflict: LocalDownloadDeleteConflict: u'Unsynced files within /Users/peterbraden/Google Drive/Photos', recovery plan: RecoveryPlan.UNKNOWN, recovery targets: set([])

2015-11-21 15:08:34,190 +0100 WARNING pid=45155 4641013760:Worker-1        workers.pyo:363 Setting recovery_targets for all changes. LocalDownloadDeleteConflict: u'Unsynced files within /Users/peterbraden/Google Drive/Photos', recovery plan: RecoveryPlan.UNKNOWN, recovery targets: set([])
2015-11-21 15:08:34,191 +0100 ERROR pid=45155 4641013760:Worker-1        fatal_exceptions.pyo:55 Ignoring non-fatal error: LocalDownloadDeleteConflict: LocalDownloadDeleteConflict: u'Unsynced files within /Users/peterbraden/Google Drive/Photos', recovery plan: RecoveryPlan.UNKNOWN, recovery targets: set([6770201, '0B4BhBBbuWQqARE9aamNOQ3U0a1k', 1590463]), Traceback:
  File "common/workers.pyo", line 186, in Process
  File "common/persistence/sqlite.pyo", line 127, in Wrapper
  File "common/workers.pyo", line 303, in _ProcessChanges
  File "common/worker/downloads.pyo", line 419, in Execute
  File "common/worker/downloads.pyo", line 483, in _DownloadDeleteFromFolder

2015-11-21 15:08:34,191 +0100 ERROR pid=45155 4641013760:Worker-1        blacklist.pyo:245 The following request has been blacklisted ImmutableChange(Direction.DOWNLOAD, Action.DELETE, ino=6770201, name=u'Photos', rid=0B4BhBBbuWQqARE9aamNOQ3U0a1k, parent_ino=1590463, is_folder=True, is_cancelled=False, is_priority=False, doc_type=DocType.FOLDER, hash=-2213610710502213993, _constructor_called=True) Because of exception: LocalDownloadDeleteConflict: u'Unsynced files within /Users/peterbraden/Google Drive/Photos', recovery plan: RecoveryPlan.UNKNOWN, recovery targets: set([6770201, '0B4BhBBbuWQqARE9aamNOQ3U0a1k', 1590463])
2015-11-21 15:08:34,194 +0100 INFO pid=45155 4641013760:Worker-1        change_buffer.pyo:288 Replacing entry in change buffer: ChangeBufferEntry(state=IN_PROGRESS, fschange=ImmutableChange(Direction.DOWNLOAD, Action.DELETE, ino=6770201, name=u'Photos', rid=0B4BhBBbuWQqARE9aamNOQ3U0a1k, parent_ino=1590463, is_folder=True, is_cancelled=False, is_priority=False, doc_type=DocType.FOLDER, hash=-2213610710502213993, _constructor_called=True), sequence_number=0)->ChangeBufferEntry(state=BLACKLISTED, fschange=ImmutableChange(Direction.DOWNLOAD, Action.DELETE, ino=6770201, name=u'Photos', rid=0B4BhBBbuWQqARE9aamNOQ3U0a1k, parent_ino=1590463, is_folder=True, is_cancelled=False, is_priority=False, doc_type=DocType.FOLDER, hash=-2213610710502213993, _constructor_called=True), blacklist_info=BlacklistInfoSub(key=u'/Users/peterbraden/Google Drive/Photos', fullname=u'Photos', direction=_DownloadDirectionType(Direction.DOWNLOAD), failure=LocalDownloadDeleteConflict(), entry_time=2292698.964972734, url=None, is_folder=True, action=_FSChangeActionType(Action.DELETE)), sequence_number=0)
2015-11-21 15:08:34,557 +0100 INFO pid=45155 4666253312:Batcher         batcher.pyo:240 Current batch is completed. Batcher snooze.
2015-11-21 15:08:34,557 +0100 INFO pid=45155 4666253312:Batcher         sync_status.pyo:133 Reset sync status
2015-11-21 15:08:34,557 +0100 INFO pid=45155 4666253312:Batcher         batcher.pyo:856 Batcher Stats = file_count = Counter({_COUNT_KEY(direction=_DownloadDirectionType(Direction.DOWNLOAD), action=_FSChangeActionType(Action.DELETE), batch=False, successful=False): 1}), byte_count = Counter(), batch_operation_count = Counter(), process_seconds = Counter({_COUNT_KEY(direction=_DownloadDirectionType(Direction.DOWNLOAD), action=_FSChangeActionType(Action.DELETE), batch=False, successful=False): 16.693994998931885}), duration seconds = 27 (start_time = 1448114886, end_time = 1448114914)

This same problem happens to me about every 3rd time I try and do something with a folder containing photos on Google Drive. It's been plaguing me for months. I'd noticed that the log said it was blacklisted, but I'd failed to notice that there was an earlier line listing offending photos. I'm going to give your solution a try the next time it occurs. I agree that this is maddening behavior on the part of Google drive.

The most annoying part to me is that if I use the Drive web UI to move the folder to another, unsynced folder (effectively deleting it from my local machine and keeping it only in the cloud), the move appears to succeed. Google Photos will start toying with it and it will appear in the correct, moved-to folder online. My desktop app will complain of a problem and show it in its original location. So I effectively have the same folder in two locations according to Google drive. Deleting it from the old location on my desktop will delete it from the new location online. My trust in my files actually being where Google claims they are is essentially gone.

As some minimal solace, I guess I'm heartened that they don't delete it if they know they have managed to mess up some files, though.