Like was recently done for preferred content, when checking numcopies for a drop, it could check if other files are using the same key, and if so check that their numcopies (and mincopies) is satisfied as well.

There would be an efficiency tradeoff of course, since it would have to query the keys db. The question I suppose is, if someone sets different numcopies for different files via .gitattributes, and they use the same key, will the user think it's a problem that numcopies can be violated in some circumstances. And I think that users would maybe consider that to be a problem, if they happened to encounter the behavior.

It may also be worth considering making --all (etc) also check numcopies of associated files. Although then, in a bare repo, it would behave differently than in a non-bare repo. (Also if this is done, the preferred content checking should also behave the same way.) The docs for --all do say that it bypasses checking .gitattributes numcopies. --Joey

Note that the assistant and git-annex sync already check numcopies for all known associated files, so already handled this for unlocked files. With the recent change to also track associated files for locked files, they also handle it for those.

But, git-annex drop/move/mirror don't yet.

fixed (did not change --all behavior) --Joey