Opened 12 years ago

Last modified 7 years ago

#499 closed defect (Fixed)

Win32 - duplicate state file created

Reported by: wraithdu Owned by:
Priority: Low Milestone:
Component: Core Tor/Tor Version: 0.1.2.16
Severity: Keywords:
Cc: wraithdu, nickm, edmanm, Silivrenion Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Tor v0.1.2.17 under Win32 (maybe others?)

When using the DataDirectory setting in my torrc file (same setting as in Vidalia) a duplicate 'state' file
is created in '%APPDATA%\tor', regardless of the setting. The rest of the files (cachedstatus, etc.) are
saved to the specified directory along with another copy of the 'state' file.

Does the Vidalia setting take precedence over the torrc setting anyway?

[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]

Child Tickets

Change History (9)

comment:1 Changed 12 years ago by nickm

Hmmm. Tor is supposed to look for a state file wherever its configured DataDirectory is, and should only
write the state file there too.

Is the state file in %APPDATA%\tor an exact copy of the other one? Do they both get changed over time?

comment:2 Changed 12 years ago by wraithdu

When I start Tor, the state file in the configured data directory is updated with the current date/time.
The copy in %APPDATA%tor (and the directory) is created newly with the same date/time if it does not first
exist. On subsequent runs, the copy in %APPDATA%tor is NOT updated. The copy in the configured directory
is updated. If the %APPDATA%tor directory is deleted, on the next run it is recreated.

I start Tor via Vidalia.

comment:3 Changed 12 years ago by nickm

Okay, that sounds like a bug, and potentially a bad one at that. I'll check it out.

comment:4 Changed 12 years ago by edmanm

This happens when Vidalia runs 'tor --hash-password <foo>' before starting Tor, so it can provide the correct
value for the HashedControlPassword argument. For some reason, Tor writes out its state file even though all it's
doing is hashing a password and then exiting immediately.

comment:5 Changed 12 years ago by nickm

Aha! Okay, not a major awful nasty bug (as it would be if that state file were influencing the Tor process),
but still a bug. We don't need the state file to hash passwords (or do anything besides run Tor, I think),
so it should be okay to just not try loading or creating it when we aren't running.

comment:6 Changed 12 years ago by Silivrenion

I found this bug myself because of the PortableTor build. I have every possible option trying to direct every temp file onto the local paths, and to find that a file was left behind despite the DataDirectory being set was surprising to me. Fixing this would solve some problems, and would really help!

comment:7 Changed 12 years ago by nickm

Fixed in svn; fix should appear in 0.2.0.7-alpha and in 0.1.2.18.

comment:8 Changed 12 years ago by nickm

flyspray2trac: bug closed.

comment:9 Changed 7 years ago by nickm

Component: Tor ClientTor
Note: See TracTickets for help on using tickets.