Hi,

It appears that Boinc Manager drops a configuration file into the home directory without hiding it:

$ file /home/user/BOINC\ Manager-user
/home/user/BOINC Manager-user: ASCII text, with no line terminators

I think this file should begin with a dot to hide it from display in the home directory or be
moved to a sub directory in a hidden directory in home.

Kitty

Hi,

I noticed after closing Boinc Manager the file is removed, so it seems to be more of a
temporary file than a configuration file.

Kitty

thanks

Hi Wxwidgets maintainers, according to boinc/upstream this might be likely a wx issue, or a wx wrong usage :)

cheers,

G.




Il Giovedì 11 Giugno 2015 10:21, David Anderson <davea@ssl.berkeley.edu> ha scritto:
According to Rom, the file name is based on the app name supplied to WxWidgets,
namely line 206 of BOINCGUIApp.cpp:

     SetAppName(wxT("BOINC Manager"));

The functions for reading/writing config info
(like window size and position) are members of the class WxConfigBase.
Wx stores this info in a file on Unix; on Win, it uses the registry.

Control: reassign -1 boinc
Control: found -1 7.4.23+dfsg-1
Control: retitle -1 boinc should specify a hidden file for wxSingleInstanceChecker

This doesn't match the pattern for configuration files - as well as no
leading ".", it has "-user" appended.  I see no wxConfig-related code
which could be doing that.  Also, the reporter said that the file is removed
upon program exit, which wxConfig created files aren't (since they are there
to persist state between runs).

I believe this file is created by wxSingleInstanceChecker, which is
instantiated with default constructor in clientgui/BOINCGUIApp.cpp.
That means that the default lockfile name is used, which is built by
this code in include/wx/singlinst.h:

    bool CreateDefault()
    {
        wxCHECK_MSG( wxTheApp, false, "must have application instance" );
        return Create(wxTheApp->GetAppName() + '-' + wxGetUserId());
    }

If boinc wants the file to be called something else, it should request
a particular filename (like it already does in the __WXMAC__ case).

Gianfranco - since you're both a maintainer of boinc and a member of the wx
maintainers team, you really are in the perfect position to dig into issues
like this where it's unclear which package is to blame.

Anyway, reassigning back to boinc.

Cheers,
    Olly

Hi Olly, of course I tried to debug the problem,
but I didn't find *who* did create the file.
Upstream told it was a config file, and I trusted that assertion, that lead me to the wrong
conclusion (even the SetAppName(wxT("BOINC Manager")) might have trapped me to that wrong path.

I'm still having issue in understanding why "wxSingleInstanceChecker()" should create a lock file in my

home directory rather than in some more appropriate file, and why the file doesn't end in .lock or whatever
that would have helped me a lot in understanding what was going on.


So not being at all a wx programmer (I went to the team to try to help with packaging issues, and to
help in having the webview support, still needed for BOINC) doesn't help me so much in debugging
this kind of troubles, so please forgive me if I need some help there :)

thanks again,

G.

It creates the lock file where you tell it to, with a default of:

homedir + "/" + appname + "-" + userid

That's arguably not a great default, but changing it now it is
established is problematic as it'll break the single instance checking
between apps using wx versions from before and after the change.

I'd expect wx upstream would only consider that at the start of a
release series.

If they're going to change, using a shared memory object seems a better
approach, so I've opened a ticket with wx upstream to suggest that:

http://trac.wxwidgets.org/ticket/17046

But changing to a shared memory object or a different default filename
unilaterally in Debian doesn't seem a good idea, so if you want to fix
this for boinc in the short term, passing an explicit location for the
file is a better plan (as the upstream code already does for OS X).
You'll also have the interoperability considerations, but they are
easier to decide for a single application as the implications of ending
up with two instances are clearer for a particular case than in general.

Cheers,
    Olly

Hi again Olly!



Really no need to patch wx for Debian :)
Upstream is discussing right now to unify the code for OS X and Unix, I'll
follow the conclusion they reach, if they reach one :)

thanks again,

Gianfranco