1318642 - presence of Unix domain sockets caused staged update to fail

Status: RESOLVED WONTFIX

(Toolkit :: Application Update, defect)

Description

[Mark Smith [:mcs]]

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?

Comment 1

[Robert Strong (they/them - no direct email)]

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.

Comment 2

[Mark Smith [:mcs]]

(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

[Robert Strong (they/them - no direct email)]

(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.

Comment 4

[Mark Smith [:mcs]]

(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.