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..
This commit is contained in:
Joey Hess 2014-02-06 14:55:11 -04:00
parent a44e01c29c
commit 0fc3ad82c5
3 changed files with 16 additions and 5 deletions

View file

@ -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.

1
debian/changelog vendored
View file

@ -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

View file

@ -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]]