TL;DR: add --ignore-unmatch.
Direct cause: git rm --cached will fail if the file does not exist in the index at the time that the git rm runs.
Background: git filter-branch works by copying commits. Precisely how it does this depends on the exact set of filter(s) chosen. You used --index-filter which is one of the simplest (and thus fastest): this one works by reading each commit to be copied into the index, then letting you run some command to alter the index, then making a new commit from whatever you have left in the index after your command.
In this case, you're copying 60 commits (1/60). Git will do this copying in the order required, which in general means starting at the very first commit ever made in the repository. It's likely that this commit does not have any dir_b/* files and/or dir_c/* files. So git rm --cached looks for files whose name starts with dir_b (and in a moment, dir_c) and does not find any such files and aborts with an error.
This stops the filter-branch operation, which leaves the repository unmodified.
The cure in this particular case is to use git rm --cached --ignore-unmatch, which tells git rm that not finding a file to remove is not an error. So now when filter-branch reads out the very first commit—which probably has just a README file or some such—it's OK to leave everything alone and re-commit that first commit. Eventually you'll reach some commits that do have the files; git rm --cached --ignore-unmatch will remove them; and the new replacement commit will be different from the original commit, so that the final tip commit of the branch will be different as well, so that the branch name will refer to the new commits instead of the old ones.
