From: Charles Oliver Nutter <Charles.O.Nutter@...>
Date: 2006-10-07T03:23:16+09:00
Subject: Re: making FileUtils.rm_rf robust: is anyone interested?

Jim Meyering wrote:
> 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.

Either way we wouldn't really be able to support it, and we'd have to 
hack our own version of FileUtils that doesn't spawn or fork anything :(

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

I do not know of any such feature in the C domain, but that's not my 
area. We emulate chdir support in JRuby by keeping a separate variable 
for cwd. When operations that are directory-sensitive are called, we 
provide the cwd for them, normalizing paths manually as necessary. So 
far it has worked fairly well for us, and a thread-specific approach 
would a logical next step.

In Java, we don't really even have the ability to chdir, so this 
emulation was the only safe way to support it.

-- 
Charles Oliver Nutter, JRuby Core Developer
headius@headius.com -- charles.o.nutter@sun.com
Blogging at headius.blogspot.com