Comment 8 for bug 479248

Sorry it took so long to reply, but the bug did not re-appear until today.

On Thu, Jan 28, 2010 at 12:06:43AM -0000, Dustin Kirkland wrote:
> Also, is the ecryptfs mount active?
>
> mount | grep ecryptfs

$ mount | grep ecryptfs
/home/username/.Private on /home/username type ecryptfs
(ecryptfs_sig=466c5178c2a30351,ecryptfs_fnek_sig=add28c0fcbae8831,ecryptfs_cipher=aes,ecryptfs_key_bytes=16)

> And are her keys properly loaded?
>
> keyctl list @u

$ keyctl list @u
2 keys in keyring:
277263190: --alswrv 1000 0 user: add28c0fcbae8831
638313147: --alswrv 1000 0 user: 466c5178c2a30351

> As for opening new shells in a screen session, screen has a behavior of
> opening each subsequent shell in the same directory as the original PWD
> at the initial start of screen. It's possible that was buggered up.
> Try exiting screen and starting a new screen session.

Opening a new terminal results in a new, valid shell.

After discussing it with her, we came up with the following scenario that
seems to cause the problem:

 1. She launches a screen session
 2. She logs off (her X session), leaving the screen detached
 3. She logs back in
 4. She re-attaches the screen, creates a new terminal, and it's broken.

That reliably reproduces the problem.

If the ecryptfs mount is automatically unmounted after 2, the working
directory of screen disappears and causes it to break. A "cd" fixes it because
it changes the working directory to her home, which is the new mount point.

What we are not sure is that if the semantics for the broken shell are
correct (i.e. consistant with the dissapearance of the underlying working
directory).

Thanks a lot,
  Alberto