mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

committer: Fix a file handle leak.

Browse source
This commit is contained in:
Joey Hess 2013-01-05 13:42:31 -04:00
parent 8f3d07b565
commit bf1981f60e
3 changed files with 9 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

3
Command/Add.hs
View file

@ -60,7 +60,8 @@ lockDown file = do
tmp <- fromRepo gitAnnexTmpDir tmp <- fromRepo gitAnnexTmpDir
createAnnexDirectory tmp createAnnexDirectory tmp
liftIO $ do liftIO $ do
(tmpfile, _handle) <- openTempFile tmp (takeFileName file) (tmpfile, handle) <- openTempFile tmp (takeFileName file)
hClose handle
nukeFile tmpfile nukeFile tmpfile
createLink file tmpfile createLink file tmpfile
return $ KeySource { keyFilename = file , contentLocation = tmpfile } return $ KeySource { keyFilename = file , contentLocation = tmpfile }

1
debian/changelog vendored
View file

@ -1,6 +1,7 @@
git-annex (3.20130103) UNRELEASED; urgency=low git-annex (3.20130103) UNRELEASED; urgency=low
* webapp: Add UI to stop and restart assistant. * webapp: Add UI to stop and restart assistant.
* committer: Fix a file handle leak.
-- Joey Hess <joeyh@debian.org> Thu, 03 Jan 2013 14:58:45 -0400 -- Joey Hess <joeyh@debian.org> Thu, 03 Jan 2013 14:58:45 -0400

6
doc/bugs/assistant___40__OS_X_Lion__41___-___34__too_many_open_files__34___error.mdwn
View file

@ -24,3 +24,9 @@ What version of git-annex are you using? On what operating system?
Please provide any additional information below. Please provide any additional information below.
I imagine I could avoid this error by using the "ulimit -n" command to increase number of files in a shell session and then running assistant manually, so this is really only a bug report about the bundled application. I imagine I could avoid this error by using the "ulimit -n" command to increase number of files in a shell session and then running assistant manually, so this is really only a bug report about the bundled application.
> This seems to be caused by Command.Add.lockdown not closing the
> temporary file handle, so when called in a mapM by the committer
> thread when there are a lot of files, it could build up a lot of
> open handles before later GC closes them. Added a manual close,
> so I think this is [[done]]. --[[Joey]]