GNU bug report logs - #10470
MSYS: race in directory access?

Previous Next

Package: automake;

Reported by: Peter Rosin <peda <at> lysator.liu.se>

Date: Mon, 9 Jan 2012 23:09:01 UTC

Severity: minor

Tags: patch

Done: Stefano Lattarini <stefano.lattarini <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Peter Rosin <peda <at> lysator.liu.se>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 10470 <at> debbugs.gnu.org
Subject: bug#10470: MSYS: race in directory access?
Date: Tue, 10 Jan 2012 19:37:47 +0100
Stefano Lattarini skrev 2012-01-10 18:03:
>>> It would probably be worthwhile to try to understand why this is the case.
>>> As a wild guess, would this work?
>>>
>>>   - ( sleep 1 ) &
>>>   + sh -c "cd '$abs_builddir'; sleep 1" &
>>
>> No, fails in the same way as the original.
>>
> Sorry, by bad, I meant this:  sh -c "cd '$ac_abs_srcdir'; sleep 1"

No, that doesn't work either, at least not if you meant the line to end
with &, as it would be an inline sleep if it wouldn't.  Side note,
$ac_abs_srcdir is empty (so it's not really "somewhere/safe", as Eric
put it).

>>> We could enhance your original workaround like this:
>>>
>>>  am__remove_distdir = \
>>>    { test ! -d "$(distdir)" \
>>>      || { find "$(distdir)" -type d ! -perm -200 -exec chmod u+w {} ';' \
>>> -         && rm -fr "$(distdir)"; }; }
>>> +         && if rm -fr "$(distdir)"; then :; else \
>>> +## On MSYS (1.0.17) it is not possible to remove a directory that is
>>> +## in use; so, if the first rm fails, we sleep some seconds and retry,
>>> +## to give pending processes some time to exit and "release" the
>>> +## directory before we removed.  See automake bug#10470.
>>> +              sleep 5 && rm -fr "$(distdir)"; fi; }; }
>>>  am__post_remove_distdir = $(am__remove_distdir)
>>>  endif %?TOPDIR_P%
>>
>> This works, best so far!  Committable, if you ask me.
>>
> I agree, but first I'd like to see if we manage to resolve the issue into
> sanity.m4 itself.  If we fail, the above workaround will be good enough.

Yes, that would be best.  Otherwise we run the risk of having to add the
workaround for other places as well, ick.

I think (but I'm out on a limb here) that it might be the make process that
invoked the distcheck rule that lingers in the build-dir until configure
(and all its children terminates).  That make is locking the directory and
causes rm to fail. But as I said, I'm out on a limb and this is probably
just crap...

Cheers,
Peter




This bug report was last modified 13 years and 134 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.