On Tue, 2016-03-15 at 17:48 +0000, Eric DeCosta wrote:
> Sure, easy enough loop around looking at the return value from
> unlink, sleeping for 0.1 sec and trying again if unlink fails. There
> still should be some maximum amount of time to try before giving up.
> Do you think 3 seconds is too long in that case?
The issue is that make takes advantage of UNIX-y filesystem semantics
(that a file can be unlinked even though it's open) to avoid some gross
coding effort. In commands.c:fatal_error_signal() see:
for (c = children; c != 0; c = c->next)
delete_child_targets (c);
/* Clean up the children. We don't just use the call below because
we don't want to print the "Waiting for children" message. */
while (job_slots_used > 0)
reap_children (1, 0);
With Windows/NTFS file system semantics, where open files cannot be
deleted, we need to finish reaping children before we try to delete the
targets.
Unfortunately, reap_children() also cleans up the "children" list and
frees the memory, so we can't simply reverse the order of these two
loops and reap first.
Figuring out a way to fix this would be yucky, but would that be better
than sleeping on file removal failure?
Or, are there other reasons on Windows why the file removal might fail
and we should do the removal loop anyway? I think at one of my
companies which supported Windows clients we had to do this loop
always, even for files we created ourselves, because you could never
tell when Windows would be walking the filesystem opening files for
various reasons (virus checking or whatever).
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
