Potential file system race

[ultimatespirit]

I've noticed this occur several times now, so I suspect it may be a file system race of some sort. Due to the nature of the bug however I can't reproduce it consistently and consequently have no verbose debug logs to share.

$ aura --version
aura 4.0.7
$ aura -Aa perl-sereal # Could be any package, this just happens to be the most recent
aura :: Determining dependencies...
aura :: Failed to parse .SRCINFO: /home/USER/.cache/aura/packages/perl-sereal-decoder/.SRCINFO
$ aura -Aa perl-sereal # immediately afterwards
# totally expected output, it all just works

I suspect what's going on is between finishing a download of a PKGBUILD and attempting to parse .SRCINFO we somehow hit a filesystem race leading to attempting to read inconsistent state, and thereby failing the parse. On the second invocation since it's cached it can't hit this case again. This also does not consistently occur, so it's not that it just always fails on first try.

...I have no explanation for how a race could be occurring here, since I haven't checked how aura actually implements the download. If download and parsing are fully serial actions there just shouldn't be a possibility for a file system race like this, and having the two actions be multi-threaded seems odd, so I'm guessing aura does not do that.

For what it's worth, I also saw the "failed to clone git repository, doesn't exist" type error I saw was reported here before. Perhaps the way aura calls out to git has some hidden issues that need further debugging?

[fosskers]

I have seen this happen and believes this to be related to #900 . I've written what I suspect is happening in that issue.

In terms of triggering it:

• It's easier to trigger for packages with large transitive dependency graphs.
• It's easier to trigger when you have few packages in ~/.cache/aura/packages/, i.e. harder when you've already pulled the offending package once.