Bug fix: export with -J could fail when two files had the same content.

Exporting is done inside a call to writeLockDbWhile which guarantees there
is only one process uploading to a given ExportLocation.

CHANGELOG

@@ -24,6 +24,7 @@ git-annex (8.20201130) UNRELEASED; urgency=medium
     include deletions of submodules.
     Thanks, Kyle Meyer for the patch.
   * Windows: Work around win32 length limits when dealing with lock files.
+  * Bug fix: export with -J could fail when two files had the same content.
 
  -- Joey Hess <id@joeyh.name>  Mon, 04 Jan 2021 12:52:41 -0400
 

Command/Export.hs

@@ -283,7 +283,11 @@ performExport r db ek af contentsha loc allfilledvar = do
 	sent <- tryNonAsync $ case ek of
 		AnnexKey k -> ifM (inAnnex k)
 			( notifyTransfer Upload af $
-				upload' (uuid r) k af stdRetry $ \pm -> do
+				-- alwaysUpload because the same key
+				-- could be used for more than one export
+				-- location, and concurrently uploading
+				-- of the content should still be allowed.
+				alwaysUpload (uuid r) k af stdRetry $ \pm -> do
 					let rollback = void $
 						performUnexport r db [ek] loc
 					sendAnnex k rollback $ \f ->

doc/bugs/export_-J_6__to_S3__58___transfer_already_in_progress.mdwn

@@ -94,3 +94,5 @@ Besides reporting the issue, I also have a question:  could I just rerun `export
 
 [[!meta author=yoh]]
 [[!tag projects/datalad]]
+
+> [[fixed|done]] bypassed this unncessary locking for exports. --[[Joey]]