This time memory leaked if lots of UUIDs needed to be pretty-printed, as in
a get or drop of many files. Essentially the same strict read buffering
problem that affected the LocationLog underneath though.
uuidMap really could stand to be cached, as the uuid log is read many times
in this case. But it is a fairly edge case.
Writing to a tmp file means no locking is needed, and it fixes a bug
introduced by the last commit, which made log files be read lazily, so
they could still be open when written, which breaks due to haskell's
internal locking.
Actions that need to read all the location logs, like "git annex get .",
were still using a lot of memory, and profiling pointed at the location log
reading as the problem. Not locking them for read, and thus avoiding the
strict reading fixes the problem, although I don't quite understand why.
(Oddly, -sstderr profiling did not show the memory as used, though top
showed dozens of MB being used.)
Anyway, it's fine to not lock location logs for read, since the log format
and parser should be safe if a partial read of a file being written happens.
Note that that could easily happen anyway, if doing a git pull, etc,
especially if git needs to union merge in changes from elsewhere. The worst
that will happen is git-annex could get a bad or out of date idea about
locations and refuse to eg, --drop something.
