Re: making FileUtils.rm_rf robust: is anyone interested?

Jim Meyering wrote:
> However, given sufficient O/S support, the implementation in
> coreutils/src/remove.c is indeed robust and thread-safe.  As of
> coreutils-6.0 (the latest is coreutils-6.3), "rm -r" can remove an
> arbitrarily deep hierarchy in a thread-safe manner on a system with
> support for openat-like functions (Linux-2.6.16 and newer and Solaris 10).
> I have taken great pains to ensure that the code degrades gracefully,
> so that it works as well (but sacrifices thread safety) on systems that
> have neither openat nor sufficient /proc support.  If you require
> thread safety even without openat support, then currently you must
> compromise on robustness: i.e., the code must once again be subject
> to the PATH_MAX limitation.

I'm not sure how much weight this will carry, but since we ship Ruby's 
libraries with JRuby we're hoping the same logic described above will be 
implementable in Java. Also ...

> 
> 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?

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