Hello again,
On Thu, 7 Feb 2008, David Landgren via RT wrote:
Show quoted text> One would just have to walk up the call stack and see if there's an
> END block there.
I didn't only mean an explicit END{} block. I intended to include all
cases where "it's the end of the program, therefore I don't care what my
cwd is after this operation."
For example: if we're in an object DESTROY call which is implicitly
called at end-of-program, silently ignoring the problem may be okay, but
if we're in a DESTROY implicitly called at the end of a lexical scope,
generating an error is more appropriate.
(My real preference is to not treat this as an error condition in any
cases, however.)
Show quoted text> What makes me hesitate is symlinks. If you're in a child directory that
> is symlinked in from elsewhere, asking to rmtree() the parent might not
> delete what you thought it would, or worse, it might delete what you
> thought it wouldn't. I guess it depends on whether the fact that
> rmtree() will delete a symlink rather than trying to read it is what you
> expected.
I think I'm confused. If you expect rmtree() to behave differently than
it does behave, how does it matter what your cwd happens to be?
It seems to me, you're describing 2 separate problems:
1. people may not have proper expectations w.r.t rmtree and symlinks.
2. rmtree considers it an error if your cwd is inside the tree
you're rm'ing.
However, I don't think that detecting case 2 is really enough to
prevent case 1 from causing problems.
Show quoted text> My personal opinion, not that it amounts to much, is a feeling that it
> is wrong to try and delete your own directory out from under you.
> Where are you afterwards?
I have my own opinions, though they're also not necessarily worth much.
If the program is about to end, then it mostly doesn't matter what your
cwd is afterwards. (It does matter if not-run-yet END code needs a
working directory.) That's the source of my compromise above for
ignoring the error at least in the "end of the world" scenario.
However:
In general, I don't chdir(). I treat the current working directory as
a global variable which I have no control over. I consider it
suspicious if anyone calls chdir(), and I prefer to always use full
paths whenever possible.
It's never truly safe to assume your cwd is valid or unchanged, after
calling someone else's code. Perl doesn't (and can't) provide a "local"-
like way to preserve cwd: cases such as the one we're describing make it
impossible.
Not only that: at any time, any process on the machine can remove your
current working directory or move it around. It's _never_ truly safe to
assume that if you chdir() to a directory, it will be there at the time
your next operation runs (except possibly on systems with OS-enforced
file locking).
Therefore, I say: give the programmer enough rope to hang themselves.
It's easy to recover from "I just deleted my cwd:" do a chdir() after
the call to rmtree() instead of before the call to rmtree().
If you program defensively and always use full paths, then you're
insulated from problems with your cwd disappearing or changing without
your knowledge.
(In my current case, I was using chdir, and I got bitten by it: more
evidence for my preference. Unfortunately, I don't think I can avoid
this particular use of chdir, but I also don't think it would be a Real
problem if File::Temp rmtree'd my cwd at end-of-perl time.)
Show quoted text> I think I would rather add a flag 'updir' => 1 which would instruct
> rmtree to chdir up out out the directory tree it was being asked to
> delete. If you want to do something semantically ambiguous I think you
> should say so.
I'm not sure this would be very useful. If you know that what you're
doing is going to cause this problem, then you can already preempt it
by using a chdir() prior to your rmtree() call. That's how I solved
my problem.
I guess my main point is: Yes, I put myself in the position of removing
my own cwd, and yes it's easy to prevent or repair this without changing
rmtree() at all.
I just think it shouldn't have been a problem in the first place.
I'm fine if this is considered "not a bug." In my initial RT report, I
mainly just wanted to point out that it's not as uncommon as it may have
seemed at the time.
Thanks!
Alan Ferrency
