Bug#924800: [PATCH] resolve race in test cleanup by making second attempt more forceful

[Joey Hess]

Sean Whitton wrote:
> Errors are like this:
> 
>     .t/gpgtest/9/S.gpg-agent.extra: removeDirectoryRecursive:removeContentsRecursive:removePathRecursive:removeContentsRecursive:removePathRecursive:removeContentsRecursive:r emovePathRecursive:getSymbolicLinkStatus: does not exist (No such file or directory)
> 
> i.e. the problem seems to be files vanishing while
> removeDirectoryRecursive is running.  removePathForcibly ignores such
> errors.

> +			removePathForcibly tmpdir

I'd certianly like to use removePathForcibly -- after all it was added
in response to a bug report I filed about this very kind of problem.

But, the first version of ghc to include it was 8.4.2, which is newer
than the 8.0 minimum I think git-annex supports now, and also newer than
what's in Debian stable. So it would need to be 
#if MIN_VERSION_directory(1,2,7)

It also seems very unlikely that something would wait around for 10
seconds while git-annex is delaying to let any processes that might be
running finish their cleanup, and then run at exactly the same time as
the removeDirectoryRecursive. Since the earlier removeDirectoryRecursive
failed on the same file, I have the feeling the problem is not actually
with the file vanishing out from under it, but something else to do with
it being a socket.. It seems to me that removePathForcibly would
probably at best ignore the error in removal and so leave a .t directory
hanging around at the end?

-- 
see shy jo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-haskell-maintainers/attachments/20190401/6daf3676/attachment.sig>