Merge branch 'master' of git://git-annex.branchable.com

18 files changed, 253 insertions, 36 deletions

diff --git a/doc/bugs/Share_with_friends_crash_in_osx/comment_10_8d90e23514d9f14283857c57017a5fcf._comment b/doc/bugs/Share_with_friends_crash_in_osx/comment_10_8d90e23514d9f14283857c57017a5fcf._comment
new file mode 100644
index 000000000..ef7579c46
--- /dev/null
+++ b/doc/bugs/Share_with_friends_crash_in_osx/comment_10_8d90e23514d9f14283857c57017a5fcf._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.68"
+ subject="comment 10"
+ date="2014-01-20T16:28:43Z"
+ content="""
+I have updated the autobuild again, now nettle is built with more optimisations disabled. I hope this fixes it because I'm running out of things to try.
+"""]]
diff --git a/doc/bugs/Share_with_friends_crash_in_osx/comment_11_1a0e174969e99e7b562854d2c3b3e606._comment b/doc/bugs/Share_with_friends_crash_in_osx/comment_11_1a0e174969e99e7b562854d2c3b3e606._comment
new file mode 100644
index 000000000..5b5b94a40
--- /dev/null
+++ b/doc/bugs/Share_with_friends_crash_in_osx/comment_11_1a0e174969e99e7b562854d2c3b3e606._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkLdR1fuu5aEz3s9VKTBKVMize_SmeNRJM"
+ nickname="David"
+ subject="Past the SHA issues"
+ date="2014-01-20T23:14:53Z"
+ content="""
+Now we still have an issue with nettle, but now it's part of urandom.  I'm not sure what to suggest...
+
+[[!format sh \"\"\"
+Thread 1 Crashed:
+0   H                             	0x00000001075d9756 do_device_source_urandom + 108
+1   H                             	0x00000001075d9686 do_device_source + 46
+2   H                             	0x00000001075d92b9 wrap_nettle_rnd_init + 74
+3   H                             	0x000000010755d585 _gnutls_rnd_init + 32
+4   H                             	0x0000000107551dae gnutls_global_init + 262
+5   git-annex                     	0x00000001054a28c3 0x103c83000 + 25295043
+6   git-annex                     	0x000000010692ab28 0x103c83000 + 46824232
+\"\"\"]]
+"""]]
diff --git a/doc/bugs/__96__minimal_build__39____fails_due_to_missing_stm_dependency.mdwn b/doc/bugs/__96__minimal_build__39____fails_due_to_missing_stm_dependency.mdwn
index 7f1dc9c0d..12a5e0c14 100644
--- a/doc/bugs/__96__minimal_build__39____fails_due_to_missing_stm_dependency.mdwn
+++ b/doc/bugs/__96__minimal_build__39____fails_due_to_missing_stm_dependency.mdwn
@@ -91,3 +91,5 @@ ExitFailure 1
 
 # End of transcript or log.
 """]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/copies.mdwn b/doc/copies.mdwn
index 93cbd8ea8..205d2d5b1 100644
--- a/doc/copies.mdwn
+++ b/doc/copies.mdwn
@@ -6,8 +6,8 @@ command.  So, git-annex can be configured to try
 to keep N copies of a file's content available across all repositories. 
 (Although [[untrusted_repositories|trust]] don't count toward this total.)
 
-By default, N is 1; it is configured by annex.numcopies. This default
-can be overridden on a per-file-type basis by the annex.numcopies
+By default, N is 1; it is configured by running `git annex numcopies N`.
+This default can be overridden on a per-file-type basis by the annex.numcopies
 setting in `.gitattributes` files. The --numcopies switch allows
 temporarily using a different value.
 
@@ -30,9 +30,3 @@ refuse to do so.
 
 With N=2, in order to drop the file content from Laptop, it would need access
 to both USB and Server.
-
-Note that different repositories can be configured with different values of
-N. So just because Laptop has N=2, this does not prevent the number of
-copies falling to 1, when USB and Server have N=1. To avoid this,
-configure it in `.gitattributes`, which is shared between repositories
-using git.
diff --git a/doc/design/assistant/telehash.mdwn b/doc/design/assistant/telehash.mdwn
index 9e1d6f613..777bce646 100644
--- a/doc/design/assistant/telehash.mdwn
+++ b/doc/design/assistant/telehash.mdwn
@@ -58,3 +58,33 @@ This might turn out to be easy to split off from git-annex, so `git pull`
 and `git push` can be used at the command line to access telehash remotes.
 Allows using general git entirely decentralized and with end-to-end
 encryption.
+
+## separate daemon?
+
+A `gathd` could contain all the telehash specific code, and git-annex
+communicate with it via a local socket.
+
+Advantages:
+
+* `git annex sync` could also use the running daemon
+* `git-remote-telehash` could use the running daemon
+* c-telehash might end up linked to openssl, which has licence combination
+  problems with git-annex. A separate process not using git-annex's code
+  would avoid this.
+* Allows the daemon to be written in some other language if necessary
+  (for example, if c-telehash development stalls and the nodejs version is
+  already usable)
+* Potentially could be generalized to handle other similar protocols.
+  Or even the xmpp code moved into it. There could even be git-annex native
+  exchange protocols implemented in such a daemon to allow SSH-less
+  transfers.
+* Security holes in telehash would not need to compromise the entire
+  git-annex. gathd could be sandboxed in one way or another.
+
+Disadvantages:
+
+* Adds a memcopy when large files are being transferred through telehash.
+  Unlikely to be a bottleneck.
+* Adds some complexity.
+* What IPC to use on Windows? Might have to make git-annex communicate
+  with it over its stdin/stdout there.
diff --git a/doc/design/external_special_remote_protocol/comment_12_e3029c65d34f78272bc11961ebfd8237._comment b/doc/design/external_special_remote_protocol/comment_12_e3029c65d34f78272bc11961ebfd8237._comment
new file mode 100644
index 000000000..e8d0dcfe8
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_12_e3029c65d34f78272bc11961ebfd8237._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawm_YXzEdPHzbSGVwtmTR7g1BqDtTnIBB5s"
+ nickname="Matthias"
+ subject="Chunk it"
+ date="2014-01-20T16:22:09Z"
+ content="""
+> TODO: stream the file up/down the pipe, rather than using a temp file
+
+You might want to use chunked transfer, i.e. a series of \"EXPECT 65536\" followed by that many bytes of binary data and an EOF marker (EXPECT-END or EXPECT 0), instead of escaping three characters (newline, NUL, and the escape prefix) and the additional unnecessary tedious per-character processing that would require.
+"""]]
diff --git a/doc/devblog/day_101__old_mistakes.mdwn b/doc/devblog/day_101__old_mistakes.mdwn
new file mode 100644
index 000000000..4a37416dc
--- /dev/null
+++ b/doc/devblog/day_101__old_mistakes.mdwn
@@ -0,0 +1,23 @@
+In order to remove some hackishness in `git annex sync --content`, I
+finally fixed a bad design decision I made back at the very beginning
+(before I really knew haskell) when I built the command seek code, which
+had led to a kind of inversion of control. This took most of a night, but
+it made a lot of code in git-annex clearer, and it makes the command
+seeking code much more flexible in what it can do. Some of the oldest, and
+worst code in git-annex was removed in the process.
+
+Also, I've been reworking the numcopies configuration, to allow for a 
+[[todo/preferred_content_numcopies_check]]. That will let the assistant,
+as well as `git annex sync --content` proactively make copies when
+needed in order to satisfy numcopies. 
+
+As part of this, `git config annex.numcopies` is deprecated, and there's a
+new `git annex numcopies N` command that sets the numcopies value that will
+be used by any clone of a repository.
+
+I got the preferred content checking of numcopies working too. However,
+I am unsure if checking for per-file .gitattributes annex.numcopies
+settings will make preferred content expressions be, so I have left
+that out for now.
+
+Today's work was sponsored by Josh Taylor.
diff --git a/doc/forum/Can_not_drop_unused_file/comment_3_0c9c9c0ed557af4845a67434c21bb4bc._comment b/doc/forum/Can_not_drop_unused_file/comment_3_0c9c9c0ed557af4845a67434c21bb4bc._comment
new file mode 100644
index 000000000..8a1ecfdd2
--- /dev/null
+++ b/doc/forum/Can_not_drop_unused_file/comment_3_0c9c9c0ed557af4845a67434c21bb4bc._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.68"
+ subject="comment 3"
+ date="2014-01-20T16:33:27Z"
+ content="""
+I see you're using encryption. That could have something to do with the problem. Which type of encryption was used for this special remote? encryption=shared or one of the other options?
+
+Look through the whole strace output for attempts to access the directory special remote and show those. Or put up the full strace somewhere.
+"""]]
diff --git a/doc/git-annex.mdwn b/doc/git-annex.mdwn
index e8058720c..8a948d303 100644
--- a/doc/git-annex.mdwn
+++ b/doc/git-annex.mdwn
@@ -403,6 +403,20 @@ subdirectories).
   keyid+= and keyid-= with such remotes should be used with care, and
   make little sense except in cases like the revoked key example above.
 
+* `numcopies [N]`
+
+  Tells git-annex how many copies it should preserve of files, over all
+  repositories. The default is 1.
+
+  Run without a number to get the current value.
+
+  When git-annex is asked to drop a file, it first verifies that the
+  required number of copies can be satisfied amoung all the other
+  repositories that have a copy of the file.
+
+  This can be overridden on a per-file basis by the annex.numcopies setting
+  in .gitattributes files.
+
 * `trust [repository ...]`
 
   Records that a repository is trusted to not unexpectedly lose
@@ -828,7 +842,7 @@ subdirectories).
 * `--auto`
 
   Enable automatic mode. Commands that get, drop, or move file contents
-  will only do so when needed to help satisfy the setting of annex.numcopies,
+  will only do so when needed to help satisfy the setting of numcopies,
   and preferred content configuration.
 
 * `--all`
@@ -883,7 +897,7 @@ subdirectories).
 
 * `--numcopies=n`
 
-  Overrides the `annex.numcopies` setting, forcing git-annex to ensure the
+  Overrides the numcopies setting, forcing git-annex to ensure the
   specified number of copies exist.
 
   Note that setting numcopies to 0 is very unsafe.
@@ -1006,6 +1020,15 @@ file contents are present at either of two repositories.
   copies, on remotes in the specified group. For example,
   `--copies=archive:2`
 
+* `--numcopiesneeded=number`
+
+  Matches only files that git-annex believes need the specified number or 
+  more additional copies to be made in order to satisfy their numcopies
+  setting, as configured by the global numcopies setting of the repository.
+
+  Note that for various reasons, including speed, this does not look 
+  at the annex.numcopies .gitattributes settings of files.
+
 * `--inbackend=name`
 
   Matches only files whose content is stored using the specified key-value
@@ -1117,12 +1140,6 @@ Here are all the supported configuration settings.
 
   A unique UUID for this repository (automatically set).
 
-* `annex.numcopies`
-
-  Number of copies of files to keep across all repositories. (default: 1)
-
-  Note that setting numcopies to 0 is very unsafe.
-
 * `annex.backends`
 
   Space-separated list of names of the key-value backends to use.
@@ -1151,6 +1168,17 @@ Here are all the supported configuration settings.
 
         	annex.largefiles = largerthan=100kb and not (include=*.c or include=*.h)
 
+* `annex.numcopies`
+
+  This is a deprecated setting. You should instead use the
+  `git annex numcopies` command to configure how many copies of files
+  are kept acros all repositories.
+
+  This config setting is only looked at when `git annex numcopies` has
+  never been configured.
+
+  Note that setting numcopies to 0 is very unsafe.
+
 * `annex.queuesize`
 
   git-annex builds a queue of git commands, in order to combine similar
@@ -1456,10 +1484,12 @@ but the SHA256E backend for ogg files:
 
 The numcopies setting can also be configured on a per-file-type basis via
 the `annex.numcopies` attribute in `.gitattributes` files. This overrides
-any value set using `annex.numcopies` in `.git/config`.
-For example, this makes two copies be needed for wav files:
+other numcopies settings.
+For example, this makes two copies be needed for wav files and 3 copies
+for flac files:
 
 	*.wav annex.numcopies=2
+	*.flac annex.numcopies=3
 
 Note that setting numcopies to 0 is very unsafe.
 
diff --git a/doc/install/fromscratch.mdwn b/doc/install/fromscratch.mdwn
index 7f78da537..2c8bf4b71 100644
--- a/doc/install/fromscratch.mdwn
+++ b/doc/install/fromscratch.mdwn
@@ -25,9 +25,9 @@ quite a lot.
   * [extensible-exceptions](http://hackage.haskell.org/package/extensible-exceptions)
   * [feed](http://hackage.haskell.org/package/feed)
   * [async](http://hackage.haskell.org/package/async)
-* Optional haskell stuff, used by the [[assistant]] and its webapp
   * [stm](http://hackage.haskell.org/package/stm)
     (version 2.3 or newer)
+* Optional haskell stuff, used by the [[assistant]] and its webapp
   * [hinotify](http://hackage.haskell.org/package/hinotify)
     (Linux only)
   * [dbus](http://hackage.haskell.org/package/dbus)
diff --git a/doc/internals.mdwn b/doc/internals.mdwn
index d95ab3f5e..1cf0cf505 100644
--- a/doc/internals.mdwn
+++ b/doc/internals.mdwn
@@ -56,8 +56,11 @@ space and then the description, followed by a timestamp. Example:
 	e605dca6-446a-11e0-8b2a-002170d25c55 laptop timestamp=1317929189.157237s
 	26339d22-446b-11e0-9101-002170d25c55 usb disk timestamp=1317929330.769997s
 
-If there are multiple lines for the same uuid, the one with the most recent
-timestamp wins. git-annex union merges this and other files.
+## `numcopies.log`
+
+Records the global numcopies setting.
+
+The file format is simply a timestamp followed by a number.
 
 ## `remote.log`
 
diff --git a/doc/preferred_content.mdwn b/doc/preferred_content.mdwn
index 9c698c8ba..b18f46c33 100644
--- a/doc/preferred_content.mdwn
+++ b/doc/preferred_content.mdwn
@@ -113,7 +113,7 @@ any repository that can will back it up.)
 All content is preferred, unless it's for a file in a "archive" directory,
 which has reached an archive repository.
 
-`((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1))) or (not copies=semitrusted+:1)`
+`((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1))) or numcopiesneeded=1`
 
 ### transfer
 
@@ -147,20 +147,20 @@ All content is preferred.
 Only prefers content that's not already backed up to another backup
 or incremental backup repository.
 
-`(include=* and (not copies=backup:1) and (not copies=incrementalbackup:1)) or (not copies=semitrusted+:1)`
+`(include=* and (not copies=backup:1) and (not copies=incrementalbackup:1)) or numcopiesneeded=1`
 
 ### small archive
 
 Only prefers content that's located in an "archive" directory, and
 only if it's not already been archived somewhere else.
 
-`((include=*/archive/* or include=archive/*) and not (copies=archive:1 or copies=smallarchive:1)) or (not copies=semitrusted+:1)`
+`((include=*/archive/* or include=archive/*) and not (copies=archive:1 or copies=smallarchive:1)) or numcopiesneeded=1`
 
 ### full archive
 
 All content is preferred, unless it's already been archived somewhere else.
 
-`(not (copies=archive:1 or copies=smallarchive:1)) or (not copies=semitrusted+:1)`
+`(not (copies=archive:1 or copies=smallarchive:1)) or numcopiesneeded=1`
 
 Note that if you want to archive multiple copies (not a bad idea!),
 you should instead configure all your archive repositories with a
diff --git a/doc/tips/using_the_web_as_a_special_remote.mdwn b/doc/tips/using_the_web_as_a_special_remote.mdwn
index 706ae2951..62ef58b69 100644
--- a/doc/tips/using_the_web_as_a_special_remote.mdwn
+++ b/doc/tips/using_the_web_as_a_special_remote.mdwn
@@ -34,7 +34,7 @@ With the result that it will hang onto files:
 	  Could only verify the existence of 0 out of 1 necessary copies
 	  Also these untrusted repositories may contain the file:
 	  	00000000-0000-0000-0000-000000000001  -- web
-	  (Use --force to override this check, or adjust annex.numcopies.)
+	  (Use --force to override this check, or adjust numcopies.)
 	failed
 
 ## attaching urls to existing files
diff --git a/doc/todo/Provide_a___34__git_annex_satisfy__95__num__95__copies__34___command.mdwn b/doc/todo/Provide_a___34__git_annex_satisfy__95__num__95__copies__34___command.mdwn
index 877e9fdbf..cbd01181f 100644
--- a/doc/todo/Provide_a___34__git_annex_satisfy__95__num__95__copies__34___command.mdwn
+++ b/doc/todo/Provide_a___34__git_annex_satisfy__95__num__95__copies__34___command.mdwn
@@ -7,12 +7,10 @@ for i in `git remote`; do git copy -to $i --auto; done
 The use case is this:
 I have a very large repo (300.000 files) in three places. Now I want the fastest possible way to ensure, that every file exists in annex.numcopies. This should scan every file one time and then get it or copy it to other repos as needed. Right now, I make one "git annex get --auto" in every repo, which is is a waste of time, since most of the files never change anyway!
 
-> The closest we have to this is the (new) `git annex sync --content`.
-> It does effectivly just what the shown for loop does.
+> Now `git annex sync --content` does effectivly just what the shown for
+> loop does. [[done]]
 > 
-> But, that actually satisfies preferred content settings, which default
-> to preferring every repo have a copy, and even if configured will
-> typically be more than numcopies.
-> 
-> Numcopies is more of a minimum lower bound (though not a hard bound).
+> The only difference is that copy --auto proactively downloads otherwise
+> unwanted files to satisfy numcopies, and sync --content does not.
+> We need a [[preferred_content_numcopies_check]] to solve that.
 > --[[Joey]]
diff --git a/doc/todo/preferred_content_numcopies_check.mdwn b/doc/todo/preferred_content_numcopies_check.mdwn
new file mode 100644
index 000000000..8aa736a04
--- /dev/null
+++ b/doc/todo/preferred_content_numcopies_check.mdwn
@@ -0,0 +1,84 @@
+The assistant and git annex sync --content do not try to proactively
+download content that is not otherwise wanted in order to get numcopies
+satisfied. (Unlike get --auto, which does take numcopies into account.)
+
+Should these automated systems try to proactively satisfy numcopies? I
+don't feel they should. It could result in surprising results. For example,
+a transfer repository, which is of limited size, could start being filled
+up with lots of content that all clients have, just because numcopies was
+set to a larger number than the total number of clients. Another example,
+a source repository on eg an Android phone, should never have content in it
+that was not created on that device.
+
+However, it would make sense for some specific 
+types of repositories to proactively get content to satisfy numcopies. 
+Currently some types of repositories use "or (not copies=semitrusted+:1)",
+to ensure that if the only copy of a file is on a dead repository, they
+will try to get that file before the repo goes away. This is done
+by client repositories, and backup, and archive. Probably the same set
+would make sense to proactively satisfy numcopies.
+
+So, a new type of preferred content expression is called for. Such as, for
+example, "numcopiesneeded=1". Which indicates that at least 1 more copy 
+is needed to satifsy numcopies. 
+
+(Note that it should only count semittrusted and higher trust
+level repos as satisfying numcopies.)
+
+But, preferred content expressions can only operate on info stored in the
+git repo, or they will fail to be stable. Ie, repo A needs to be able to
+calculate whether a file is preferred content by repo B and get the same
+result as when repo B calculates that.
+
+numcopies is currently configured in 3 places:
+
+* .git/config `annex.numcopies` (global, stored only locally)
+* .gitattributes `annex.numcopies` (per file, stored in git repo)
+* --numcopies (not relevant)
+
+So, need to add a global numcopies setting that is stored in the git repo.
+That could either be a file in the git-annex branch, or just
+`* annex.numcopies=2` in the toplevel .gitattributes. Note that the
+assistant needs to be able to query and set it, which I think argues
+against using .gitattributes for it. Also arguing against that is that the
+.git/config numcopies valie applies even to objects with no file in the
+work tree, which gitattributes settings do not.
+
+Conclusion:
+
+* Add to the git-annex branch a numcopies file that holds the global
+  numcopies default if present. **done**
+* Modify the assistant to use it when configuring numcopies. **done**
+* To deprecate .git/config's annex.numcopies, only make it take effect
+  when there is no numcopies file in the git-annex branch. **done**
+* Add "numcopiesneeded=N" preferred content expression using the git-annex
+  branch numcopies setting, overridden by any .gitattributes numcopies setting
+  for a particular file. It should ignore the other ways to specify
+  numcopies, particularly git config annex.numcopies. **done**
+* Make the repo groups that currently end with "or (not copies=semitrusted+:1)"
+  to instead end with "or numcopiesneeded=1" **done**
+* See if "numcopiesneeded=N" can check .gitattributes without getting
+  a lot slower. If now, perhaps add a "numcopiesneededaccurate=N" that
+  checks it.
+
+## Stability analysis
+
+If a remote prefers eg, "blah or numcopiesneeded=1", and
+file $foo does not match blah, but needs more copies, then then the
+expression will match.
+
+So, git-annex will get $foo, adding a copy. Which means that the 
+numcopiesneeded=1 will no longer match, so the file is no longer wanted
+now that it has been downloaded.
+
+Now there are two cases for what can happen:
+
+* git-annex tries to drop $foo, but fails because it cannot find enough
+  other copies
+* git-annex copies $foo to some other remote that wants it, and then
+  manages to drop $foo from the local remote.
+
+This seems ok. Files flow through repos and they act like transfer
+repos when there are not enough copies.
+
+--[[Joey]]
diff --git a/doc/todo/wishlist__91__webapp__93__:_add_an_option_to_install__SSH_key_on_remote.mdwn b/doc/todo/wishlist__91__webapp__93__:_add_an_option_to_install__SSH_key_on_remote.mdwn
index 297047e06..fe32f7dd7 100644
--- a/doc/todo/wishlist__91__webapp__93__:_add_an_option_to_install__SSH_key_on_remote.mdwn
+++ b/doc/todo/wishlist__91__webapp__93__:_add_an_option_to_install__SSH_key_on_remote.mdwn
@@ -1,3 +1,9 @@
 When adding a Remote server through the webapp, it set-up a specific SSH key for later sync.
 
 However, when the remote has been set-up manually, then later gets the assistant thrown at it, there doesn't appear to be a way to create and deploy such a key. This option could be offered in, e.g., the settings of the repo in the webapp.
+
+> I feel this is out of scope for the assistant. If the user is able to
+> manually add a git remote at the command line, then they should be able
+> to configure ssh keys too. I don't want to complicate the assistant with
+> a lot of code that tries to deal with half-configured things the user
+> manually set up. [[wontfix|done]] --[[Joey]]
diff --git a/doc/walkthrough/fsck:_verifying_your_data.mdwn b/doc/walkthrough/fsck:_verifying_your_data.mdwn
index d036332fb..62e15b6fa 100644
--- a/doc/walkthrough/fsck:_verifying_your_data.mdwn
+++ b/doc/walkthrough/fsck:_verifying_your_data.mdwn
@@ -2,7 +2,7 @@ You can use the fsck subcommand to check for problems in your data. What
 can be checked depends on the key-value [[backend|backends]] you've used
 for the data. For example, when you use the SHA1 backend, fsck will verify
 that the checksums of your files are good. Fsck also checks that the
-annex.numcopies setting is satisfied for all files.
+[[numcopies|copies]] setting is satisfied for all files.
 
 	# git annex fsck
 	fsck some_file (checksum...) ok
diff --git a/doc/walkthrough/removing_files:_When_things_go_wrong.mdwn b/doc/walkthrough/removing_files:_When_things_go_wrong.mdwn
index 2d3c0cde0..ccd2d197f 100644
--- a/doc/walkthrough/removing_files:_When_things_go_wrong.mdwn
+++ b/doc/walkthrough/removing_files:_When_things_go_wrong.mdwn
@@ -10,12 +10,12 @@ you'll see something like this.
 	  Try making some of these repositories available:
 	   	58d84e8a-d9ae-11df-a1aa-ab9aa8c00826  -- portable USB drive
 	   	ca20064c-dbb5-11df-b2fe-002170d25c55  -- backup SATA drive
-	  (Use --force to override this check, or adjust annex.numcopies.)
+	  (Use --force to override this check, or adjust numcopies.)
 	failed
 	drop other.iso (unsafe)
 	  Could only verify the existence of 0 out of 1 necessary copies
           No other repository is known to contain the file.
-	  (Use --force to override this check, or adjust annex.numcopies.)
+	  (Use --force to override this check, or adjust numcopies.)
 	failed
 
 Here you might --force it to drop `important_file` if you [[trust]] your backup.