fix temp filename

Was not putting it inside the temp dir, but next to it!

This was just wrong, and it led to a longer filename that desired being
used, leading to some bug reports.

Annex/ReplaceFile.hs

@@ -30,7 +30,7 @@ replaceFile file action = do
 	filemax <- liftIO $ fileNameLengthLimit misctmpdir
 	let basetmp = take (filemax `div` 2) (takeFileName file)
 	withTmpDirIn misctmpdir basetmp $ \tmpdir -> do
-		let tmpfile = tmpdir <> basetmp
+		let tmpfile = tmpdir </> basetmp
 		action tmpfile
 		liftIO $ replaceFileFrom tmpfile file
 

debian/changelog

@@ -20,6 +20,8 @@ git-annex (5.20151117) UNRELEASED; urgency=medium
     This was a reversion caused by the relative path changes in 5.20150113.
   * dropunused: Make more robust when trying to drop an object that has
     already been dropped.
+  * Fix reversion in handling of long filenames, particularly when using
+    addurl/importfeed, which was introduced in the previous release.
 
  -- Joey Hess <id@joeyh.name>  Mon, 16 Nov 2015 16:49:34 -0400
 

doc/bugs/20151116_tests_fail_on_OS_X.mdwn

@@ -36,3 +36,5 @@ FAIL (0.29s)
   (This could be due to a bug in git-annex, or an incompatability
    with utilities, such as git, installed on this system.)
 ```
+
+> [[fixed|done]] --[[Joey]]

doc/bugs/20151116_tests_fail_on_OS_X/comment_2_59f7803b9a9ee939a8a50605fe5c4682._comment

@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-12-06T20:02:49Z"
+ content="""
+Ok, this involves where the test suite is run.
+The addurl test adds `file://`pwd`/somefile`, and that will create a file
+with a name like `_home_you_sub_dir_path_here_somefile`. Which can easily
+exceed filename length limits of 255 bytes.
+
+There was indeed a reversion in addurl's handling of that.
+"""]]

doc/bugs/importfeed_fails_on_createSymbolicLink___40__but_ln_-s_works__41__.mdwn

@@ -46,3 +46,5 @@ Debian amd64 unstable package 5.20151116-1.
 ### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
 
 That’s just a little hiccup in, up to now, various months of merry use! ;-)
+
+> [[fixed|done]] --[[Joey]]

doc/bugs/importfeed_fails_on_createSymbolicLink___40__but_ln_-s_works__41__/comment_1_c831256a081b181a121910aca3151e45._comment

@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-12-06T19:50:59Z"
+ content="""
+I can reproduce this.
+
+	symlink("../.git/annex/objects/fK/9M/URL--http&c%%mvod.lvlt.rtve.es%resour-39e58395b01e2385d46bade56127cfc4/URL--http&c%%mvod.lvlt.rtve.es%resour-39e58395b01e2385d46bade56127cfc4", ".git/annex/misctmp/Documentos_RNE___Coss\303\255o_y_la_Casona_de_Tudanca__refugio_de_la_cultura_espa\303\261ola_entre_las_monta\303\261as_de_Cantabria___28_08_15.mp3.0Documentos_RNE___Coss\303\255o_y_la_Casona_de_Tudanca__refugio_de_la_cultura_espa\303\261ola_entre_las_monta\303\261as_de_Cantabria___28_08_15.mp3") = -1 ENAMETOOLONG (File name too long)
+
+The problem is not the length of the link target, which is only 170
+characters and will work on any OS. The basename of the symlink
+being created is pretty long, 294 characters, and that's the
+cause of the failure.
+
+	joey@darkstar:~>ln -s /dev/null $(perl -e 'print ("a" x 294)')
+	ln: failed to create symbolic link ‘aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa’ -> ‘/dev/null’: File name too long
+
+The limit is 255 characters in a single path component (`pathconf _PC_NAME_MAX`).
+
+So, the issue is caused by the rss feed having a long title for this
+item.
+
+And this used to work; it's a recent reversion. Fixing.
+"""]]