diff --git a/doc/forum/Should_transfer_to_a_special_remote_verify_source_content__63__.mdwn b/doc/forum/Should_transfer_to_a_special_remote_verify_source_content__63__.mdwn
new file mode 100644
index 0000000000..42bde18da0
--- /dev/null
+++ b/doc/forum/Should_transfer_to_a_special_remote_verify_source_content__63__.mdwn
@@ -0,0 +1,63 @@
+A [DataLad issue](https://github.com/datalad/datalad/issues/4795) was
+raised about users inadvertently corrupting locked files.  That led to
+an example where a user could copy corrupted content over to a special
+remote, and the content isn't flagged until a `get` call.  (A slightly
+different example, based on a directory remote and without
+`exporttree=yes`, is included below.)
+
+In the case of a regular remote, the `copy` call would fail earlier
+with
+
+```
+  verification of content failed
+
+  failed to send content to remote
+
+
+  verification of content failed
+
+  failed to send content to remote
+failed
+git-annex: copy: 1 failed
+```
+
+Should something similar happen when copying or exporting to a special
+remote?  Perhaps verification before transfer to a special remote
+isn't worth it, but the successful transfer surprised me given the
+behavior when transferring to regular remotes.
+
+[[!format sh """
+cd "$(mktemp -d "${TMPDIR:-/tmp}"/dl-XXXXXXX)"
+
+mkdir d
+git init a
+(
+    cd a
+    git annex init
+
+    echo one >one
+    git annex add one
+    git commit -mone
+
+    one_resolved=$(readlink -f one)
+    chmod +w $one_resolved
+    echo more >>$one_resolved
+    chmod -w $one_resolved
+
+    git annex initremote d type=directory directory="$PWD"/../d encryption=none
+    git annex copy --to=d
+
+    git annex drop --force one
+    git annex get one
+)
+"""]]
+
+```
+[...]
+copy one (to d...)
+ok
+(recording state in git...)
+```
+
+[[!meta author=kyle]]
+[[!tag projects/datalad]]