The following reply was made to PR bin/46148; it has been noted by GNATS.
From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost,
tron%zhadum.org.uk@localhost
Subject: Re: bin/46148: cvs(1) broken in NetBSD 6.0_BETA
Date: Sat, 24 Mar 2012 17:41:31 +0000
On Sat, Mar 24, 2012 at 04:45:02AM +0000, Matthew Mondor wrote:
> I have no idea yet if this could be related, and if so, in which
> situation this happens, but xcvs uses chdir(2) a lot, and I wonder if
> the cwd is always consistent. It might be quick to assume a problem
> with chdir/cwd, but I noticed that on netbsd-6 with ff8 (I never had
> that problem with ff8 on netbsd-5), ff sometimes goes back to the
> previous-previous directory that was used to save a file rather than
> the previous one. And gtkfilechooser does use chdir. Of course, it
> also could be a bug in ff8 or gtk2...
I find this highly improbable -- the current directory is a vnode
reference saved in the process structure. If it were changing behind
the process's back to some other vnode because of e.g. a refcounting
or locking issue, it's highly unlikely you'd see specifically the
previous-previous directory; you'd get some arbitrary directory or
strange behavior because a regular file got picked up instead.
Likewise for the chdir call retrieving and setting the wrong vnode.
(And if the pointer were getting arbitrarily corrupted, you'd be
seeing crashes.)
It's much more likely that ff8 has a bug. It may not even be using the
current directory as such to manage the state for that file-save
dialog; I noticed with recent seamonkey that setting the cwd before
starting the browser no longer initializes the default file save path
for you.
--
David A. Holland
dholland%netbsd.org@localhost