'pin rm' in the context of broken pins

From IRC (Starting around 16:00 EDT on Mar 17, 2017):

**kevina:** whyrusleeping: would you mind if I take a pass on the pinning code and try to make pinning operations more more robust in general?
**kevina:** I will do it in small steps and explain what I did to make reviewing easier.
**kevina:** The GC should fail if there are pinned objects can't be retrieved, but other operations don't need to fail...
**whyrusleeping:** kevina: hrm... what changes are you thinking?
**kevina:** like when we scan for an indirect pin, don't abort if a pinned object is unavailable, instead issue a warning and continue
**kevina:** and possible if necessary add a "--force" option to pin rm
**whyrusleeping:** kevina: hrm... on the pinning stuff
**whyrusleeping:** the problem here is that if even a single indirectly pinned block is missing, it invalidates any guarantees we might have about the rest of the pinset
**whyrusleeping:** we essentially at that point have a set of things that are for sure pinned
**whyrusleeping:** and everything else might be pinned
**kevina:** whyrusleeping: correct, but in some cases it may be okay to continue on a best effort bases.
**kevina:** in the G.C. no
**whyrusleeping:** yeah
**kevina:** listing pins maybe
**kevina:** removing pins, yes
**kevina:** etc.
**whyrusleeping:** Yeah, if we're trying to check if a thing *is* pinned
**whyrusleeping:** we can return true or ERROR CANT TELL
**whyrusleeping:** which might be acceptable for some usecases
**kevina:** something like that
**whyrusleeping:** what would be useful though, would be to say "recursive pin X references a missing block indirectly"
**whyrusleeping:** and have ways to remedy that
**kevina:** correct
**\*** whyrusleeping thinks about the UX of an 'ipfs pin repair'
**kevina:** it should always be possible to remove a pin
**whyrusleeping:** as long as you always understand the consequences of doing so
**kevina:** I do. I wrote the G.C. code to be very careful
**kevina:** really case by case, what would happen if we ignore the missing/bad block
**whyrusleeping:** i didnt mean we as devs
**whyrusleeping:** i meant we as users
**whyrusleeping:** at any time a user is going to remove a pin like this, it needs to be very apparent the consequences
**kevina:** I understand, that why I suggested a "--force" option if it becomes required
**kevina:** actually, for removal I can't think of anything bad that can happen by removing a recursive pin where part of the pin is missing
**kevina:** the worst that can happen is we might not detect a block is pinned directly and report PIN NOT FOUND instead of reporting the recursive pin pinning it
**kevina:** so now that I think of it a "--force" option it not needed for removal expect to save time by avoiding the indirect check...
**whyrusleeping:** kevina: The issue is that the recursive pin we force remove might be a block that is referenced by a pinned block that is missing
**whyrusleeping:** and we won't be able to tell that
**whyrusleeping:** so while removing one broken pin might seem fine, it doesnt give the context that its removal also might result in the loss of data from other pins