From 18851f0e8fc12978907bc596e3392de3b8f27e3a Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 4 Apr 2016 15:42:33 -0400 Subject: v6: Close pointer file handles more quickly, to avoid problems on Windows. Was using L.readFile, so the Handle would remain open until the garbage collector got around to it. Changed to explicit open and close, so we know it's always closed when the function returns. --- Annex/Link.hs | 10 +++++++--- debian/changelog | 1 + doc/bugs/Windows__58___git_annex_get_failed.mdwn | 2 ++ ...mment_2_0866038e64aa20c3b9ba3b3190074293._comment | 20 ++++++++++++++++++++ 4 files changed, 30 insertions(+), 3 deletions(-) create mode 100644 doc/bugs/Windows__58___git_annex_get_failed/comment_2_0866038e64aa20c3b9ba3b3190074293._comment diff --git a/Annex/Link.hs b/Annex/Link.hs index b191bce6f..44c567837 100644 --- a/Annex/Link.hs +++ b/Annex/Link.hs @@ -157,10 +157,14 @@ formatPointer k = - - Unlocked files whose content is present are not detected by this. -} isPointerFile :: FilePath -> IO (Maybe Key) -isPointerFile f = catchDefaultIO Nothing $ do - b <- L.take maxPointerSz <$> L.readFile f - let !mk = parseLinkOrPointer' (decodeBS b) +isPointerFile f = catchDefaultIO Nothing $ bracket open close $ \h -> do + b <- take (fromIntegral maxPointerSz) <$> hGetContents h + -- strict so it reads before the file handle is closed + let !mk = parseLinkOrPointer' b return mk + where + open = openBinaryFile f ReadMode + close = hClose {- Checks a symlink target or pointer file first line to see if it - appears to point to annexed content. diff --git a/debian/changelog b/debian/changelog index 71744bfef..04fe35efa 100644 --- a/debian/changelog +++ b/debian/changelog @@ -12,6 +12,7 @@ git-annex (6.20160319) UNRELEASED; urgency=medium Thanks, Robie Basak * log: Display time with time zone. * log --raw-date: Use to display seconds from unix epoch. + * v6: Close pointer file handles more quickly, to avoid problems on Windows. -- Joey Hess Wed, 23 Mar 2016 11:42:36 -0400 diff --git a/doc/bugs/Windows__58___git_annex_get_failed.mdwn b/doc/bugs/Windows__58___git_annex_get_failed.mdwn index 78b964de3..6c7416653 100644 --- a/doc/bugs/Windows__58___git_annex_get_failed.mdwn +++ b/doc/bugs/Windows__58___git_annex_get_failed.mdwn @@ -3,6 +3,8 @@ I'm using git-annex v6 in windows and seems `git annex get` fails. Deleting the pointer files and doing a hard reset seems to fix the problem. Another bug report named "v6 repo can not restore files with executable permission" seems to point to the same problem but a little different. +[[!retitle "git annex get fails sometimes in v6 repository on Windows"]] + ### What steps will reproduce the problem? I have a repo in D:\annex with a file `test` Now I create another repo: diff --git a/doc/bugs/Windows__58___git_annex_get_failed/comment_2_0866038e64aa20c3b9ba3b3190074293._comment b/doc/bugs/Windows__58___git_annex_get_failed/comment_2_0866038e64aa20c3b9ba3b3190074293._comment new file mode 100644 index 000000000..4e77a505c --- /dev/null +++ b/doc/bugs/Windows__58___git_annex_get_failed/comment_2_0866038e64aa20c3b9ba3b3190074293._comment @@ -0,0 +1,20 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 2""" + date="2016-04-04T19:24:08Z" + content=""" +Note that v6 mode is still considered experimental. + +I know that I saw a problem like this, where git-annex was reading the +pointer file and didn't always get around to closing it before it tried to +replace it. I thought I fixed it back in February though -- but that fix +may have bit rotted; looking at the current code, I think it could leave +the file open until a GC pass, so if the GC doesn't always +run in time, that could explain the reported indeterminacy. + +Please paste the actual version of git-annex you're using, +"latest build from source" is a little bit vague. + +Since you are building from source, you might try pulling; +I've made a change that may fix it again. +"""]] -- cgit v1.2.3