Opened 9 years ago

Closed 2 years ago

#1680 closed defect (wontfix)

Implicit (default) state file lines hard for external apps to know

Reported by: arma Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-client
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


Right now we have stanzas in relay state files like:

BWHistoryReadEnds 2010-07-08 17:52:41
BWHistoryReadValues 438064128,395179008,...

but we leave "BWHistoryReadInterval 900" implicit because it's the default value from config.c.

That's fine -- if we ever change the default, we'll have to teach Tor to look at the TorVersion line in the state file, and derive the correct default when loading the state file.

But now we have apps like arm looking at our state file. Those apps need to know that a missing value means 900, and if we ever change it, they need to know what Tor versions have what defaults. Having that logic separately in every controller app is the wrong place for it.

Does that mean we want a "getstate" controller option (along with a getinfo state/names), and it will write out the lines it would write to the state file, but include the defaults?

Or should we just write the defaults to the state file, and call that close enough? It seems we shouldn't do that, since I can imagine two classes of defaults (first is "I don't care what the value is, please choose the right number for me Tor", and the second is "I am relying on this number, and it happens to be the default number") and we don't distinguish between them. On the third hand, I don't actually see any of the former category in _state_vars[] in config.c, so maybe I'm generalizing too much.

Child Tickets

Change History (6)

comment:1 Changed 9 years ago by Sebastian

I think the right thing to do is to export the info via the controller. Controllers might run remotely, without direct access to the state file or, maybe more commonly, run as a different user without read access.

So if controllers like to parse things from the state dir, I think that's fine; but if it breaks, they get to keep both pieces. If they want the info reliably, they should just ask Tor for it (and Tor should provide it, of course).

comment:2 Changed 9 years ago by nickm

Milestone: Tor: unspecified

I agree with sebastian; the state file is not part of Tor's interface.

comment:3 Changed 8 years ago by arma

Ok. I suggest we close this bug then with a plan of implementing getinfo state stuff a la proposal 173.

Oh, and somebody should actually implement these parts of 173. :)

comment:4 Changed 7 years ago by nickm

Keywords: tor-client added

comment:5 Changed 7 years ago by nickm

Component: Tor ClientTor

comment:6 Changed 2 years ago by nickm

Resolution: wontfix
Severity: Normal
Status: newclosed
Note: See TracTickets for help on using tickets.