Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Removing a watched node from the file system wreaks havoc #61

Open
danielpunkass opened this issue May 13, 2012 · 4 comments
Open

Removing a watched node from the file system wreaks havoc #61

danielpunkass opened this issue May 13, 2012 · 4 comments

Comments

@danielpunkass
Copy link
Contributor

  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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Collaborator

Daniel, did this one ever get fixed?

danielpunkass pushed a commit to danielpunkass/iMedia that referenced this issue May 8, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants