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.

diff --git a/Annex/ReplaceFile.hs b/Annex/ReplaceFile.hs
index b6126ba7eeb513ab5d0a3bfe347308d5ba5ebf59..94d2688a18a9c19949b1f33d3f4405eddf5bf6fc 100644 (file)
--- a/Annex/ReplaceFile.hs
+++ b/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
 

diff --git a/debian/changelog b/debian/changelog
index fae4b598b4c6de56dcf0613e58250f1e46363170..80a44c175179bec83c718a6041b2adff28e44f30 100644 (file)
--- a/debian/changelog
+++ b/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
 

diff --git a/doc/bugs/20151116_tests_fail_on_OS_X.mdwn b/doc/bugs/20151116_tests_fail_on_OS_X.mdwn
index e1db603cb6993122b8cfbf5b4ef9a271c17ae2e6..17b66bbabb2381ebf09a4bb214b81b7408747a15 100644 (file)
--- a/doc/bugs/20151116_tests_fail_on_OS_X.mdwn
+++ b/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]]

diff --git a/doc/bugs/20151116_tests_fail_on_OS_X/comment_2_59f7803b9a9ee939a8a50605fe5c4682._comment b/doc/bugs/20151116_tests_fail_on_OS_X/comment_2_59f7803b9a9ee939a8a50605fe5c4682._comment
new file mode 100644 (file)
index 0000000..01da6e8
--- /dev/null
+++ b/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.
+"""]]

diff --git a/doc/bugs/importfeed_fails_on_createSymbolicLink___40__but_ln_-s_works__41__.mdwn b/doc/bugs/importfeed_fails_on_createSymbolicLink___40__but_ln_-s_works__41__.mdwn
index 27316f1e350598f7d984d6da0669e61ec4e611a8..74a3c6c22fd48557ea3b7cb99d4baa328f593a8b 100644 (file)
--- a/doc/bugs/importfeed_fails_on_createSymbolicLink___40__but_ln_-s_works__41__.mdwn
+++ b/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]]

diff --git a/doc/bugs/importfeed_fails_on_createSymbolicLink___40__but_ln_-s_works__41__/comment_1_c831256a081b181a121910aca3151e45._comment b/doc/bugs/importfeed_fails_on_createSymbolicLink___40__but_ln_-s_works__41__/comment_1_c831256a081b181a121910aca3151e45._comment
new file mode 100644 (file)
index 0000000..b60e0f3
--- /dev/null
+++ b/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.
+"""]]