On Mon, Sep 13, 2004 at 10:29:15AM +0200, Marco d'Itri wrote:
> [Please Cc me, I'm not subscribed.]
Date: Mon, 13 Sep 2004 10:29:15 +0200
From: Marco d'Itri <[EMAIL PROTECTED]>
To: [email protected]
Subject: EOVERFLOW while accessing /dev/pts/256
Message-ID: <[EMAIL PROTECTED]>
Reply-To: [email protected], [EMAIL PROTECTED]
Mail-Followup-To: [email protected]
I'm about ready to remove Mail-Followup-To: support misfeatures from my
local mutt packages for this and various other reasons, but you're
going to confuse the 99.99% of mutt users without strong enough
stomachs to do anything but projectile vomit when attempting to hack
mutt source or who are otherwise unable to do so. I may not have such.
On Mon, Sep 13, 2004 at 10:29:15AM +0200, Marco d'Itri wrote:
> I'm not even sure this is a bug... But it almost looks like that old
> pty devices are not reused.
> What can I do to regain access to my screen session? Rebooting this
> this server would be quite painful.
> [EMAIL PROTECTED]:~$ uname -a
> Linux attila 2.6.6-b50 #1 Mon May 10 23:30:25 CEST 2004 ppc GNU/Linux
> [EMAIL PROTECTED]:~$ tty
> /dev/pts/256
> [EMAIL PROTECTED]:~$ screen -x
> Cannot access '/dev/pts/256': Value too large for defined data type
> [Exit 1]
screen(1) wasn't properly compiled with -D_FILE_OFFSET_BITS=64; it
wouldn't see -EOVERFLOW for such if it used stat64. The minor < 256
check is only used in old_valid_dev(), which in turn is only used in
the non-stat64 syscall variants. new_valid_dev() always returns 1.
-- wli
