work around absNormPath not working on Windows

Seems I punted on this while porting before. This hack relies on DOS not
using / in filenames, it's effectively an alternate path separatr in at
least current versions of windows..

3 files changed, 16 insertions, 5 deletions

diff --git a/Utility/Path.hs b/Utility/Path.hs
index 44ac72f06..0b15e7421 100644
--- a/Utility/Path.hs
+++ b/Utility/Path.hs
@@ -21,10 +21,10 @@ import Control.Applicative
 import Data.Char
 import qualified System.FilePath.Posix as Posix
 #else
-import qualified "MissingH" System.Path as MissingH
 import System.Posix.Files
 #endif
 
+import qualified "MissingH" System.Path as MissingH
 import Utility.Monad
 import Utility.UserInfo
 
@@ -34,15 +34,15 @@ import Utility.UserInfo
  -
  - On Unix, collapses and normalizes ".." etc in the path. May return Nothing
  - if the path cannot be normalized.
- -
- - MissingH's absNormPath does not work on Windows, so on Windows
- - no normalization is done.
  -}
 absNormPath :: FilePath -> FilePath -> Maybe FilePath
 #ifndef mingw32_HOST_OS
 absNormPath dir path = MissingH.absNormPath dir path
 #else
-absNormPath dir path = Just $ combine dir path
+absNormPath dir path = todos <$> MissingH.absNormPath (fromdos dir) (fromdos path)
+  where
+	fromdos = replace "\\" "/"
+	todos = replace "/" "\\"
 #endif
 
 {- Returns the parent directory of a path.
diff --git a/debian/changelog b/debian/changelog
index 5bfb26194..3c5d46de4 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -28,6 +28,7 @@ git-annex (5.20140128) UNRELEASED; urgency=medium
     directories.
   * Windows: Fix deletion of repositories by test suite and webapp.
   * Windows: Test suite 100% passes again.
+  * Windows: Fix bug in symlink calculation code.
 
  -- Joey Hess <joeyh@debian.org>  Tue, 28 Jan 2014 13:57:19 -0400
 
diff --git a/doc/bugs/On_Windows_the_Comitted_Symlinks_are_not_Relative.mdwn b/doc/bugs/On_Windows_the_Comitted_Symlinks_are_not_Relative.mdwn
index 159e48310..3ea44f857 100644
--- a/doc/bugs/On_Windows_the_Comitted_Symlinks_are_not_Relative.mdwn
+++ b/doc/bugs/On_Windows_the_Comitted_Symlinks_are_not_Relative.mdwn
@@ -90,3 +90,13 @@ The output of `git log -p` for me:
     @@ -0,0 +1 @@
     +.git/annex/objects/5X/qQ/SHA256E-s19915186--c6dc288ec8a77404c0ebc22cbe9b4ec911103fd022c3ca74eec582604dff80a7.exe/SHA256E-s19915186--c6dc288ec8a77404c0ebc22cbe9b4ec911103fd022c3ca74eec582604dff80a7.exe
     \ No newline at end of file
+
+> [[fixed|done]] -- I didn't notice this before because it happened to do
+> the right thing if you cd'd into the subdir before adding the file there.
+>
+> WRT the slow down issue, I don't see how it could matter to git-annex on
+> Windows whether the symlinks point to the right place. It only looks at
+> the basename of the symlink target to get the key. If you have a
+> repository that behaves poorly, you can probably use --debug to see if
+> git-annex is calling some expensive series of git commands somehow.
+> --[[Joey]]