Hi All/Mike, My apologies for spinning up another thread. The original seemed like it was getting cluttered, and I believe the cause has been found.
In this installation, the Tor bundle was installed in %PROGRAMFILES%. Specifically, C:\Program Files (x86)\Tor Browser. If I run "Start Tor Browser.exe" as a regular user, I receive an error message, "Firefox is already running, but not responding...". See "tor-firefox-windows-already-running.png" at http://postimg.org/image/cf8ily0sp/. When I trace the processes involved (Start Tor, Tor, and Firefox) using Sysinternal's Process Monitor, it appears Firefox is trying to write a lock file in %PROGRAMFILES%. The lock file is ...\Tor Browser\FirefoxPortable\Data\Profile\parent.lock, and it results in an ACCESS_DENIED. See "tor-firefox-windows-access-denied.png" at http://postimg.org/image/xlzmb3j1b/. If I run "Start Tor Browser.exe" as an Administrator, the browser works fine. When the Tor Browser is launched after installation (as part of the installation), the browser works fine. I believe this is because the setup/install program is not dropping privileges after it completes. In this case, FirefoxPortable should probably be writing its lock file to a temporary directory or the User's application data directory (CSIDL_APPDATA or FOLDERID_RoamingAppData, http://msdn.microsoft.com/en-us/library/windows/desktop/dd378457%28v=vs.85%29.aspx). It should not attempt to write to a read/execute directory. Jeff On Fri, Jun 14, 2013 at 10:39 PM, Mike Perry <mikepe...@torproject.org> wrote: > The new TBB 3.0 series is almost ready for its first alpha release! > > Here are the major highlights of the 3.0 series: > > 1. Usability, usability, usability! We've attempted to solve several > major usability issues in this series, including: > > A. No more Vidalia. The Tor process management is handled by the Tor > Launcher extension. If you want the Vidalia features, you can > point an existing Vidalia binary at control port 9151 after Tor > Browser has launched, and it should still work. > > B. The browser now uses a local about:tor homepage instead of > check.torproject.org. A local verification against the control port > is still performed, to ensure Tor is working, and a link to > check.torproject.org is provided from the about:Tor homepage > for manual verification as well. > > C. For Windows users: an NSIS-based extractor now guides you through > the TBB extraction and ensures the extracted bundle ends up on your > Desktop, or in a known location chosen by you. Hopefully this > will mean no more losing track of the extracted bundle files! > > 2. The bundles are all under the 25M gmail attachment size limit, so > direct email and gettor attachments are once again possible. > > 3. We now use Gitian to build the bundles. The idea behind Gitian is to > allow independent people to take our source code and produce exactly > identical binaries on their own. We're not quite at the point where > you always get a matching build, but the remaining differences are > minor, and within a couple more releases we should have it fully > reproducible. For now, we are posting all of the builds for > comparison, and you can of course build and compare your own: > > https://gitweb.torproject.org/builders/tor-browser-bundle.git/blob/HEAD:/gitian/README.build > > > Please try these out, test them, and give us feedback! The plan is to > post them on the blog by Monday, unless something goes horribly wrong. _______________________________________________ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
