When annex.numcopies is 4, and there are only 4 copies of a file, git-annex drop behaves like this:

drop me (locking a2...) (locking a3...) (locking a4...) (unsafe)
  Could only verify the existence of 3 out of 4 necessary copies

That is unnecessary work, because the drop cannot possibly succeed when there are not more than numcopies. It should be able to skip locking the content on remotes and immediately fail.

A user reported a situation where this happened to a lot of files and caused rate limiting and slowed down git-annex sync. --Joey

I started to implement making git-annex drop check if it could possibly succeed before starting locking content, and found that it was complicating it with a lot of fairly redundant code.

And since this command is run usually by the user when they really want to drop something, not in a more general situation like git-annex sync is, it seems ok for it to do a little bit of extra work, showing what remotes it's able to lock, before failing, even though it was always going to fail in the end. And if the user wants it to avoid that, they can use --auto, which already avoids doing anything when it cannot succeed.

So, I've decided to leave git-annex drop as it is. But what about git-annex sync? I tried it, and when there are not enough copies it does not appear to try to drop at all.

done --Joey