[tor-bugs] #12088 [Pluggable transport]: goptlib should provide a method for querying the state location.

Tor Bug Tracker & Wiki blackhole at torproject.org
Sun May 25 19:40:14 UTC 2014


#12088: goptlib should provide a method for querying the state location.
-------------------------------------+------------------------------
     Reporter:  yawning              |      Owner:  dcf
         Type:  enhancement          |     Status:  needs_review
     Priority:  normal               |  Milestone:
    Component:  Pluggable transport  |    Version:
   Resolution:                       |   Keywords:  goptlib, library
Actual Points:                       |  Parent ID:
       Points:                       |
-------------------------------------+------------------------------

Comment (by yawning):

 Replying to [comment:8 dcf]:
 > About error reporting: suppose your transport needs to create its own
 subdirectories in the state dir. You call pt.MakeStateDir, then you
 manually create the directories inside it. Suppose the creation of one of
 these directories fails. Is that an ENV-ERROR? If not, then a failure to
 create the state dir itself probably should also not be an ENV-ERROR.
 (Except to the extent that we abuse ENV-ERROR as a general-purpose error
 logging function.)

 This is true.  As far as what the API does, I would prefer it to always
 ENV-ERROR, or never so the error handling in the applications can do the
 right thing (and if the latter, I will more than likely continue to abuse
 ENV-ERROR as a general purpose error reporting mechanism till something
 better comes around, because providing 0 feedback to the actual user is
 terrible).

 > CMETHOD-ERROR/SMETHOD-ERROR could be a good way to report these kinds of
 generic errors that happen at startup. "CMETHOD-ERROR foo failed to create
 state directory." The only thing is I bet application authors want to
 handle all the state dir stuff once at the top of their program, before
 they enter the CMETHOD processing loop. It kind of makes me wish for a
 GENERIC-ERROR that could appear at any time during negotiation.

 I kind of like the #9957 approach here ("Spam errors to stderr, tor will
 propagate the complaints to interested parties").  It's simple, and the
 code is technically done, so it's more likely to exist sooner than adding
 new statements to the PT protocol.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/12088#comment:9>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list