fix confirmed

This commit is contained in:
Joey Hess 2020-10-05 14:36:36 -04:00
parent d74d978968
commit 36ebcd94aa
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
3 changed files with 22 additions and 7 deletions

View file

@ -32,3 +32,5 @@ I also wonder if it is possible to avoid dealing with locales upon **every** inv
[[!meta author=yoh]]
[[!tag projects/datalad]]
> [[fixed|done]] --[[Joey]]

View file

@ -12,13 +12,14 @@ eventually gets cleaned up in all circumstances.
rm: cannot remove '/home/yoh/.cache/git-annex/locales/bb375eb6ec0d2706f1723307f068911a': Directory not empty
I think what happened there is, the first process created
that cache directory, but had not yet written the base file
when the second process ran. So the second process sees what looks like a
cache directory with no base file, so it decides to clean it up. In the
meantime the first process has written base and other files and so the rm
fails. Also, the first process may succeed and end up running git-annex
with some locale files missing (if the rm happened to delete those),
resulting in incompatable system locales being used.
that cache directory, and was in the middle of writing/overwriting the
base file when the second process ran. So the second process sees what
looks like a cache directory with a missing or empty base file, so it
decides to clean it up. In the meantime the first process has written
base and other files and so the rm fails. Also, the first process may
succeed and end up running git-annex with some locale files missing
(if the rm happened to delete those), resulting in incompatable
system locales being used.
So, it ought to defer cleaning up old caches until after it's made sure its
current cache is all set up. Then that race goes away.

View file

@ -0,0 +1,12 @@
[[!comment format=mdwn
username="joey"
subject="""comment 5"""
date="2020-10-05T18:31:26Z"
content="""
The test case works a bit inconsistently, I had the best luck
first removing ~/.cache/git-annex/locales/ and the running the test case
twice in a row, which made it reliably reproduce that error on the second
run.
After the above fixes, the test case no longer reproduces the problem.
"""]]