Removing a watched node from the file system wreaks havoc

[danielpunkass]

1. Add a custom folder to the iMedia folders list by dragging it in from the Finder.
2. Quit iMedia
3. Delete the folder from the Finder
4. Reopen iMedia

Result: A hideous, useless error is displayed:

"The operation could not be completed. No other information is available about the problem."

Worse, the error is displayed once per app-launch, when the iMedia browser is first loaded.

Worst of all: the error is caused because of this residual custom folder being configured in iMedia, but it can't open it. Since it can't open it, the folder is not even displayed in the tree list, so the "bad" folder cannot even be removed properly from iMedia. The only workaround is currently to hand-edit the preferences file or zap it and start from scratch.

I don't know if this situation got worse after recent changes I made to error handling with folder parsing. I'm going to look into this soon unless somebody gets inspired to do it first.

[danielpunkass]

I have narrowed the change in behavior down to the changes Mike made in ebfc4a9.

It seems the failure being propagated in this case causes a nil NSError even though the read has failed. So the old logic of testing against nil NSError happened to produce the desired behavior of simply omitting the problematic folder, without displaying a nagging error panel.

[danielpunkass]

In -[IMBFolderParser nodeWithOldNode:options:error:], there is a test for whether the node's folder exists or not. If it doesn't exist, then it just returns nil for the node, without doing anything to the NSError output variable.

[danielpunkass]

So, 706f998 and earlier, the behavior for IMBFolderParser-backed nodes, when the underlying node disappeared from the filesystem, was to return nil from nodeWithOldNode. Because the NSError in IMBCreateNodeOperation was left alone as nil, the "success" path of:

[self performSelectorOnMainThread:@selector(_didCreateNode:) withObject:newNode];

Was reached, albeit with a nil newNode. The important thing here though was that the presence of stale custom folder parser configurations was simply ignored. The node didn't appear, and the user wasn't notified of any error.

I think this behavior is desirable, as the user may have configured custom folder sources e.g. on external volumes that are only sometimes there. In this case, the custom configuration should persist (it does in both cases currently, whether the error is displayed or not), but it should just silently fail to show up.

Do other folks have thoughts on how this should be solved? One thought is that a proper NSError should be propagated from IMBFolderParser when the underlying file is not found, but then the IMBCreateNodeOperation should be decide whether some error conditions are not worth reporting to the user.

[mikeabdullah]

Daniel, did this one ever get fixed?