svn commit: r272372 - stable/10/bin/rm

[Bruce Evans]

On Thu, 2 Oct 2014, John Baldwin wrote:

> On Thursday, October 02, 2014 2:16:28 am Glen Barber wrote:
>> On Thu, Oct 02, 2014 at 02:56:05PM +1000, Bruce Evans wrote:
>>> On Wed, 1 Oct 2014, Glen Barber wrote:
>>>
>>>> Log:
>>>> MFC r268376 (imp):
>>>>
>>>>   rm -rf can fail sometimes with an error from fts_read. Make it
>>>>   honor fflag to ignore fts_read errors, but stop deleting from
>>>>   that directory because no further progress can be made.
>>>
>>> I asked for this to be backed out in -current.  It is not suitable for
> MFC.
>>
>> It fixes an immediate issue that prevents high-concurrent make(1) jobs
>> from stomping over each other.
>>
>> If there is a more suitable solution, it needs to be introduced in head/
>> first, pending MFC for 10.1-RELEASE.
>>
>> In the meantime, we lack any alternate fix, and this resolves the
>> immediate issue at hand.
>>
>>> See old mail for more details.
>>
>> I saw the original email.  I do not see a proposed patch.

My mail gave hints for hundreds of patches.  None of them are good enough
to propose.  You could at least limit the special case to the errno that
fts_read() returns when it gets confused instead of ignoring all errors.

> I think the proposed patch is to revert this and fix the broken Makefiles
> instead.  The problem with changing rm to workaround a bug in FreeBSD's
> Makefiles is we are breaking rm(1) for everyone else in the world to cater to
> a bug in our build system.

There is still the larger problem with fts_read().  Applications like rm
are specified to do a complete tree walk, with special handling for files
that do not exist.  If fts_read() is going to abort in the middle of a
tree walk, then it is unusable for implementing applications like rm.

> Are you happy that we are invoking the same commands in parallel for a make
> target?  In some cases it may be ok, but there are many others where it is not
> (e.g. if two jobs are both compiling the same .o file, the second one might
> replace an object file out from under a subsequent link that starts after the
> first one finishes).  Instead of breaking rm, you should be harassing whoever
> broke make (or added the SUBDIR_PARALLEL logic).  Presumably you can build
> without -j <x> as a workaround.

Even multiple rm -f's for cleaning an otherwise static tree aren't
safe unless rm -f works as specified.  It's hard to think of a single
safe example using standard utilities (except make itself, used more
carefully).

Bruce