[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-talk] Firefox Portable and Access Denied on Lock File (Windows, x64) (Was: Tor Browser Bundle 3.0alpha1 test builds)
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
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
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,
It should not attempt to write to a read/execute directory.
On Fri, Jun 14, 2013 at 10:39 PM, Mike Perry <mikeperry@xxxxxxxxxxxxxx> 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:
> 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