Backtalk Crash

Dec 14 04:32 UTC 2017

Backtalk often crashes when I try to open an item from the web 
interface. Should I post the dump that comes with the error page, or is 
it useless since there's no one able to debug Backtalk around any more?

response 2 of 24:

Dec 18 05:57 UTC 2017

Changing color schemes (I've tried several) doesn't seem to reduce 
crash frequencies. Global and conference-level functions seem OK, but 
the system tends to crash when I try to open individual conference 
items. It's so frequent that the web interface is almost unusable. THIS 
item is the only one I've been able to open from the web today.

response 4 of 24:

Dec 22 20:07 UTC 2017

Might be due to all the system updates we've done since it was
first written (like a decade or more back in time).  It would
be good if it can be fixed. People do use the web interface quite
a bit.  I tend to use the command line interface but sometimes
I use the web bbs just to do something different.

response 6 of 24:

Feb 8 19:32 UTC 2018

Yes i am having the same problems also. It seems to crash on certain
conferences and not others. 

response 8 of 24:

May 9 03:59 UTC 2018

I'm conducting an experiment. I've changed the name of my ~/.cfdir 
directory so that to back- and fronttalk it looks like I've never used 
the conference system. Now I'm using the bt web interface (only) both 
anonymously and logged-in. I can read and post to conferences as ex
expected with no crashes so far.

In attempting to build and install bt, I realized that it is first and 
foremost a WEB-based conference system. This wasn't obvious to me 
because I first came to Grex looking for a shell-based community and
first  first started exploring the conferences from my shell account,
which means  means I was entering bt indirectly through the fronttalk
shell interf interface. 

My theory is that there are parts of bt (like the read status markers)
that that are designed with the assumption that the web interface will
be ever every user's first introduction to bt, and that using ft will
come late later, if ever. The crashes were happening because I'd
accessed the conf conferences first through ft, and it had set up my
status data in a way that that was incompatible with bt checking on my
status from the web.

If I continue to find no problems using bt from the web, the next step
is is to try ft again and see if it can nicely share the status data
that bt bt has initialized.

response 10 of 24:

May 9 11:02 UTC 2018

Fascinating.

On my shell account, I see that because of my access from the web bt has
 recreated my .cfdir and the read marker files inside with owner cfadm
and  group people but readable by others.

fronttalk sort-of works. I can browse conferences, and the "new" command
 takes me through conferences I added to my hotlist on the web. However,
I  can only read items in conferences that I haven't previously visited
in  bt, and the read marks don't get updated for items When I leave ft I
see  new read marker files in .cfdir/ for the conference I visited in
ft, but  its owner is me instead of cfadm.

It looks to me like the cause of the bt crashes and read marker problem
in  ft are both due to conflicting file permissions where bt creates
user  status files owned by cfadm but ft uses the player's own ID as
file owner.

response 12 of 24:

May 10 03:57 UTC 2018

Subtle indeed.

After a little more poking around I have to modify my story slightly.

BT does not create the ~/.cfdir directory. For BT users who never use FT
FT, read marker files are kept by BT in it's own directory. ~/.cfdir is
cr created the first time you use FT from the shell, copying marker
files fr from BT's directory to ~/.cfdir. Permissions on ~/.cfdir are
711.

BT starts crashing after your first use of FT if you try to view an 
item in a previously unvisited conference while logged-on. It's because
i it's trying to create a read marker file for the new conference in
your ~ ~/.cfdir, but doesn't have permission to create the file since BT
is r running as user cfadm.

response 14 of 24:

May 10 07:43 UTC 2018

- or -

c) Get BT and FT out of each other's hair and mirror user read markers 
and other status in both BT-space and FT-space (user ~/.cfdir). Then wh
when either BT or FT starts they first check if the user's status on th
the opposite side is more recent than its own, and if so synchronizes it
its status. It would eliminate the need for the twins to be writing fi
files in directories originally created by the other twin.

This would take more coding than a) or b), and worst-case-scenario is 
that it would take twice the disk space to store user read status (but 
that take so much space?), but at first blush this feels like it might 
be the right thing to do.

response 16 of 24:

May 10 19:10 UTC 2018

resp:14 I think that if you're using fronttalk and don't care about the
web interface, you don't need to do much special: just run it.

I think it's a compile-time option to tell it where to store
participation files, etc. By default it does it in it's own
tree, but you can tell it to use $HOME/.cfdir.  I forget how,
though....