Closed
Bug 1318642
Opened 8 years ago
Closed 8 years ago
presence of Unix domain sockets caused staged update to fail
Categories
(Toolkit :: Application Update, defect)
Toolkit
Application Update
Tracking
()
RESOLVED
WONTFIX
Tracking | Status | |
---|---|---|
firefox53 | --- | affected |
People
(Reporter: mcs, Unassigned)
Details
(Whiteboard: [tor])
The Tor Browser updater (a slightly modified version of the Firefox one) failed on Linux due to the presence of a Unix domain socket in a directory that was within the scope of the updater. From the updater log: ensure_copy: failed to open the file for reading: /home/user/tb-test/Browser/TorBrowser/Data/Tor/control.socket, err: 6 The problem occurred because Tor Browser users a portable directory layout on Linux where some user data is located within the scope of the installation directory, and the tor process created a Unix domain socket there. Tor ticket: https://trac.torproject.org/projects/tor/ticket/20691 We have a trivial fix which we are testing: modify ensure_copy_recursive() to skip Unix domain sockets. Would Mozilla be willing to accept such a patch?
Reporter | ||
Updated•8 years ago
|
Whiteboard: [tor]
![]() |
||
Comment 1•8 years ago
|
||
I would be ok with taking this patch if it had a test to go with it. Out of curiosity, why not go with an installation directory with a structure where there is a subdirectory with the browser and another subdirectory with the data side by side with each other? It would prevent issues like this and likely others such as extremely large files that come up and speed up update staging as well.
Reporter | ||
Comment 2•8 years ago
|
||
(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #1) > I would be ok with taking this patch if it had a test to go with it. Thanks. We will see if we can create a test. > Out of curiosity, why not go with an installation directory with a structure > where there is a subdirectory with the browser and another subdirectory with > the data side by side with each other? It would prevent issues like this and > likely others such as extremely large files that come up and speed up update > staging as well. That is the direction we are headed (e.g., on Mac OS we already use a "side-by-side" approach), but for historical reasons we are not there yet on Linux and Windows. You are correct that the side-by-side approach avoids a lot of problems.
![]() |
||
Comment 3•8 years ago
|
||
(In reply to Mark Smith (:mcs) from comment #2) > (In reply to Robert Strong [:rstrong] (use needinfo to contact me) from > comment #1) > > I would be ok with taking this patch if it had a test to go with it. > > Thanks. We will see if we can create a test. > > > Out of curiosity, why not go with an installation directory with a structure > > where there is a subdirectory with the browser and another subdirectory with > > the data side by side with each other? It would prevent issues like this and > > likely others such as extremely large files that come up and speed up update > > staging as well. > > That is the direction we are headed (e.g., on Mac OS we already use a > "side-by-side" approach), but for historical reasons we are not there yet on > Linux and Windows. You are correct that the side-by-side approach avoids a > lot of problems. Hmmm... given the above I don't think I would take the patch since it just adds another one-off that won't be applicable once you've implemented side by side.
Reporter | ||
Comment 4•8 years ago
|
||
(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #3) > Hmmm... given the above I don't think I would take the patch since it just > adds another one-off that won't be applicable once you've implemented side > by side. Okay. Your position is perfectly reasonable. Tor Browser will keep this as its own patch until we move to the side-by-side solution.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•