diff --git a/Remote/Helper/Chunked.hs b/Remote/Helper/Chunked.hs
index 2ef8360181..0cd316a4ba 100644
--- a/Remote/Helper/Chunked.hs
+++ b/Remote/Helper/Chunked.hs
@@ -120,6 +120,10 @@ storeChunks
 	-> Annex ()
 storeChunks u chunkconfig encryptor k f p storer checker = 
 	case chunkconfig of
+		-- Only stable keys are safe to store chunked,
+		-- because an unstable key can have multiple different
+		-- objects, and mixing up chunks from them would be
+		-- possible without this check.
 		(UnpaddedChunks chunksize) -> ifM (isStableKey k)
 			( do
 				h <- liftIO $ openBinaryFile f ReadMode
diff --git a/doc/bugs/possible_data_loss_when_unsized_key_stored_chunked.mdwn b/doc/bugs/possible_data_loss_when_unsized_key_stored_chunked.mdwn
index 1183398175..677dd49043 100644
--- a/doc/bugs/possible_data_loss_when_unsized_key_stored_chunked.mdwn
+++ b/doc/bugs/possible_data_loss_when_unsized_key_stored_chunked.mdwn
@@ -39,3 +39,10 @@ since it can fail so badly with them, and they're kind of a side thing?
 (Could continue retrieving, for whatever is stored hopefully w/o being
 corrupted already.)
 --[[Joey]]
+
+> This would also affect any key that is not stable.
+> And oh, it stopped using chunks to store non-stable keys in 2014.
+> 
+> So, this can't really happen with url keys, because they're not stable.
+> Ok, not a bug then, because if the key is stable, there can only be one
+> object for it, by definition. Whew! [[done]] --[[Joey]]