This will not be of use to many, if any, but I expended effort trying to figure out how to solve this today, so I’m posting it here for future reference, if nothing else.
Today, at work, I ssh’d to my home computer, and tried to run ‘screen -r -d‘, to reattach to an existing session of gnu screen at home. Here’s what happened:
$ screen -r -d
There is no screen to be detached.
I knew this was not true, so I tried this:
$ screen -list
No Sockets found in /tmp/uscreens/S-myusername.
I didn’t believe it, because I knew I had an existing session open, so I looked for myself:
$ ls -l /tmp/uscreens/S-myusername/
total 2
-rw——- 1 myusername None 54 Jul 24 14:35 1696.tty0.spugbrap-home
-rw——- 1 myusername None 54 Aug 2 14:19 3500.tty0.spugbrap-home
I saw it right there, so I looked to see if one of the processes that I had running in my existing screen session was still running:
$ ps | grep perl
3204 368 3204 1760 13 1003 14:20:05 /usr/bin/perl
Sure enough, there it was… So, I took a look at my SockDir on my laptop, at work, to see if permissions might be involved in some way:
$ ls -l /tmp/uscreens/S-myusername/
total 3
srwx—— 1 myusername None 53 Aug 2 14:18 2568.tty1.dave-laptop
srw——- 1 myusername None 53 Jul 4 01:05 3600.tty1.dave-laptop
srw——- 1 myusername None 53 May 15 15:42 960.tty1.dave-laptop
Ah hah! There was a difference! The ’s’ at the beginning of the permissions list on my laptop’s SockDir contents, but not on my home machine’s.
So, I went searching for what the heck that ’s’ stands for, since usually, if anything, I either see an ‘l’ (L) or a ‘d’. I checked the help, info, and man pages for ‘ls’ and ‘chmod’, but didn’t find anything that actually matched this flag. The closet thing was ’suid + executable’, but when I tried to chmod that onto one of my files, the permissions showed ‘-rws——’, which is not what I was looking for.
A google search or two, for things like ‘srwx——‘, ‘srw——-‘, ‘srwx srw‘, ‘cygwin srw‘, etc. didn’t turn up anything useful - at least not in the first pages of results.
I tried looking at my laptop’s SockDir in windows explorer, and looking at the advanced security properties of one of the files. Nothing looked interesting. Then I looked at it from a command prompt (4nt), and saw this:
[c:\]dir c:\cygwin\tmp\uscreens\S-myusername
[…]
0 bytes in 0 files and 2 dirs
Oops, let’s try with ‘attrib’ instead of ‘dir’:
[c:\]attrib c:\cygwin\tmp\uscreens\S-myusername
__SA_ C:\cygwin\tmp\uscreens\S-myusername\2568.tty1.dave-laptop
__SA_ C:\cygwin\tmp\uscreens\S-myusername\3600.tty1.dave-laptop
__SA_ C:\cygwin\tmp\uscreens\S-myusername\960.tty1.dave-laptop
Ah hah! The ’system’ and ‘archive’ attributes were set on these files. So, I verified that these flags were NOT set on the files on my home machine:
$ attrib “c:\\cygwin\\tmp\\uscreens\\S-myusername\*”
C:\cygwin\tmp\uscreens\S-myusername\1696.tty0.spugbrap-home
C:\cygwin\tmp\uscreens\S-myusername\3500.tty0.spugbrap-home
Sure enough, there’s the difference. So, I set the ’system’ attribute on those files (didn’t bother with ‘archive’ attribute, though I’m not sure what causes it to be there on my laptop but not on my home):
$ attrib +”c:\\cygwin\\tmp\\uscreens\\S-myusername\*”
Verified that it worked:
srw——- 1 myusername None 54 Jul 24 14:35 1696.tty0.spugbrap-home
srw——- 1 myusername None 54 Aug 2 14:19 3500.tty0.spugbrap-home
Then, I tried connecting to my existing session, and it succeeded.
While preparing this post, I experimented a little bit more, and noticed that, for some reason, my home pc is not creating these screen socket files with the required ’system’ attribute at all, anymore. I’m not sure why this is happening, now, because I can’t think of anything I’ve done, recently, that might have caused any different behavior as far as permissions and such.
I will post again if I figure this out, but for now I am content with adjusting the attribute manually. In theory, I can keep each screen session alive until my next reboot (which is rare), so I shouldn’t have to do too many manual adjustments like this. I also welcome any comments on how to solve this problem, or any other useful tips for effectively using gnu screen in cygwin.