Re: bin/46148: cvs(1) broken in NetBSD 6.0_BETA

[David Holland <dholland-bugs%netbsd.org@localhost>]

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