[resend]
Charles Oliver Nutter <Charles.O.Nutter / Sun.COM> wrote:
> Jim Meyering wrote:
...
>> However a robust, efficient, *and* always-thread-safe implementation
>> is possible: if the PATH_MAX limitation is encountered, incur the cost
>> of a single fork and then perform the remaining operations (including
>> f/chdir calls) from a separate process.
>
> We would strongly prefer to avoid any implementation that requires fork,
> since we can't really support fork in JRuby. Also, wouldn't a fork
> preclude this method from working on Windows?

With WOE, it wouldn't perform a "fork" per se.
There, rm_rf could use "spawnvp" to execute a new command
to handle the unusual event that it encounters the PATH_MAX limit.
The gnulib execute module provides a portable way to do that:
http://cvs.savannah.gnu.org/viewcvs/gnulib/lib/execute.c?root=gnulib&view=markup
But I'm no Windows expert, so take this with a big grain of salt.

> Wouldn't it perhaps be better to support chdir at a per-thread level?

Do you know how to do that portably, so that it affects only
rm_rf?  What if some other concurrently-running code requires
the process-wide semantics of chdir?  So imagine that there is
a new function with the thread-local semantics.  Maybe...
But is it available now?