Joey Hess [Mon, 19 Oct 2020 17:13:49 +0000 (13:13 -0400)]
don't try to remove pre-commit-annex and post-update-annex-hooks
Those are not installed by git-annex but by the user, and so removal
will never find the default content, and so if the user did install
them, it would display a misleading message.
Seems better, since the user installed them, to let the user remove them
if they want to.
Joey Hess [Mon, 19 Oct 2020 15:14:01 +0000 (11:14 -0400)]
switch to Haskell2010
When I put in Haskell98 this spring, I was under the mistaken
apprehension that ghc defaulted to that. But it actually its default
is a third mode, which is closer to Haskell2010 but with some differences.
The manual says "By default, GHC mainly aims to behave (mostly) like a
Haskell 2010 compiler"
Fixed two cases where the Haskell98 do indentation flexability let
wrongly indented code build. That is one of the places where
ghc does not behave like Haskell2010 by default.
The other place that I think I was concerned about, is GHC manual
section 19.1.1.3. Expressions and patterns. But that only seems to
affect code using bottoms, so would only affect pure functions throwing
an error, which I don't think git-annex does in many places as it's
pretty horrid style. And it would only affect rare cases like shown in
that section. If it did happen, it would mean that the error was not
thrown before specifying Haskell98, and then was. Haskell2010 behaves
the same as Haskell98.
This commit was sponsored by Denis Dzyubenko on Patreon.
Joey Hess [Tue, 13 Oct 2020 20:31:01 +0000 (16:31 -0400)]
Fix a memory leak introduced in the last release
The problem was this line:
cleanup = and <$> sequence (map snd v)
That caused all of v to be held onto until the end, when the cleanup action
was run.
I could not seem to find a bang pattern that avoided the leak, so I
resorted to a IORef, rather clunky, but not a performance problem because
it will only be written once per git ls-files, so typically just 1 time.
This commit was sponsored by Mark Reidenbach on Patreon.
Joey Hess [Thu, 8 Oct 2020 14:50:39 +0000 (10:50 -0400)]
Fix build on Windows with network-3
inet_addr was removed, but all this needs is localhost, so hardcoding it
should work fine.
It may be that this windows ifdef is no longer needed. It was added in 2013
with a note that getAddrInfo didn't work on windows, but it seems likely
such a problem would have been fixed since.
Joey Hess [Tue, 6 Oct 2020 12:46:35 +0000 (08:46 -0400)]
move cache cleanup back to before cache creation
It was moved to avoid a race, but that's now avoided in another way.
I prefer having it here, because this way if it somehow fails and
deletes the locpath that is going to be used, at least it will get
re-created.
Joey Hess [Mon, 5 Oct 2020 18:17:46 +0000 (14:17 -0400)]
fully atomic LOCPATH populating
This fixes a race between two runshells from two different
bundles. One could have run the cache cleanup code, seen the
LOCPATH the other one was in the process of populating, which didn't
have a base or a buildid file written yet, and so the cache cleanup code
would delete it out from under the other process.
Also, doing it fully atomically simplifies where the races between two
runshell processes from the same bundle. Now that needs to be
dealt with to only the mv that puts it in place.
Note that, if the same bundle has 2 runshells run first thing, they will
both generate locales, which is unncessary work, but that should be a
very unusual circumstance and after the LOCPATH is set up, it won't
happen again anyway.
Joey Hess [Mon, 5 Oct 2020 18:07:27 +0000 (14:07 -0400)]
move cache cleanup to avoid a race
This should fix doc/bugs/standalone_runshell_can_race_and_fail_to_remove___96____126____47__.cache__47__git-annex__47__locales__47____96___dirs
where 2 runshells were running and the second one tried to clean up
LOCPATH while the first one was still populating it.
By moving the cleanup until after LOCPATH is populated, we guarantee
it's populated, so don't need to worry about such a race with another
process populating our same LOCPATH.
Joey Hess [Mon, 5 Oct 2020 17:53:43 +0000 (13:53 -0400)]
include buildid in LOCPATH
This avoids the possibility that the bundle could be updated in place,
leading to LOCPATH existing but containing locales for the old version,
which needed to be tested for with code that was not race-free.
LOCPATH/buildid is still written and checked when cleaning up stale caches.
That is not actually necessary, except old versions of the standalone
bundle expect to see it, and this prevents them cleaning up the locale
cache of a new version. And still checking it prevents the new version
cleaning up the locale cache of the old version while the old version is
still in use.
Added explicit tests before creating LOCPATH and the base and buildid files.
The buildid file no longer needs to be updated every time, because it's
stable for the given LOCPATH directory.
And the base file actually did not need to be updated every time,
because the LOCPATH is derived from base, so if the bundle is moved
elsewhere, a different LOCPATH will be used.
Transitioning to this will mean that two git-annex builds that otherwise
have the same buildid -- the same git-annex md5sum -- will use different
LOCPATH values, but that's handled fine by the cache cleanup code, so at
most it will mean one extra generation of the locale files.
projects / git-annex.git / log