mscore -F does not delete ~/.config/MuseScore/MuseScore2.ini.lock, causing musescore to freeze whenever try to modify the .ini

I forgot the .lock in the title.

What do the dev's think about my suggestion to remove the .lock file when executing -F? Any takers on this issue? If not, I'm self-assigning.

I see in code that thirdparty/singleapp/src/qtlockedfile.cpp is responsible for locking files. I think I just need to find where musescore does its factory reset, and then add code to remove a lock if exists.

it might be an ubuntu-specific issue. Ubuntu has lockfile (http://manpages.ubuntu.com/manpages/vivid/man1/lockfile-progs.1.html) which creates locks. I will look into what creates the lock file.

lasconic says his guess is QtSingleapplication. I will look into that...I will see when code from the either qtlockedfile.cpp or qtlockedfile.cpp get invoked.

I can reporduce on Arch Linux if I first install lockfile-progs and then execute:

cd ~/.config/MuseScore
lockfile-create MuseScore2.ini
mscore
if I try to do any action that would modify the .ini, then musescore will freeze.
Musescore will be unfrozen when I execute: lockfile-remove MuseScore2.ini

Presumably, one could replicate on any debian-derived distro by first installing sudo apt-get install lockfile-progs and then perform the same replication steps. I don't know how lockfiles work on mac or win.

I'm going to self-assign and fix by deleting the lock file on the ini during factory reset. (I'd like to do this in a cross-platform manner, so if anyone could enlighten me as to how musescore uses lockfiles in mac or win, that would be nice.)

I'm not going to attempt to fix why the lock file was created and not destroyed in the first place. As I suggested in the bug description, "for some reason the semaphore was created during an action that would modify the .ini file, but execution quit before the action was completed", which would happen if mscore crashed when writing to the ini file. I expect the .ini should still be locked after such a crash. So I don't think there is a need to have crash detection logic which would erase the lock. Best to leave erasing the lock to the factory reset code, so I'll modify where #7 points to.

I haven't looked at musescore file writing code, but my general recommendation is that locks should always be used when writing over files, on any OS, be they configuration files or scores, and that file overwrite should be an atomic operation, such that the file is either completely overwritten or not overwritten at all, so it is never left in a partially written state. This might be a separate feature request (if this is not already implemented).

on a side note, looks like QT >= 5.4.0 implements atomic writes on QSettings (https://bugreports.qt.io/browse/QTBUG-21739), which is a good thing (would rather have have an older version of the .ini file with the lock engaged, rather than have a semi-overwritten .ini file).

Reading http://lists.qt-project.org/pipermail/interest/2015-February/015559.html I see that "QSettings since Qt 5.4 use QSaveFile to write, which in turn uses QLockFile"

To answer my earlier question about how to remove the lock in a OS-agnostic manner, I guess http://doc.qt.io/qt-5/qlockfile.html should do that.

I did two different implementations, so lasconic can close the one he rejects:

• Simple one-line fix using QFile to remove the .lock file: https://github.com/musescore/MuseScore/pull/2200
• A more "proper" fix utilizing Qt5's QLockFile class:
  1. remove stale settings .lock via removeStaleLockFile() forcibly
  2. try to lock
  3. delete settings
  4. unlock
  and prints meaningful qDebug qWarning messages on failure
  https://github.com/musescore/MuseScore/pull/2201

Now I am not sure I should always assume that extension is ".lock" on any OS, but I can't really find any official documentation on that.

I've tested the first fix on both x86-64 arch linux and lubuntu 15.04, and verified will delete a .lock file on that settings. I've only tested the second fix on my arch linux machine (didn't bother on the ubuntu machine since it takes too long to compile). They both passed travis.

The other thing that I think I should mention, is that musescore 2.0.2 on my arch linux machine has different behavior than on the ubuntu machine, such that if I've created a lock file already, my arch linux machine will stall for only about 30 seconds instead of indefinately. I think this behavior changed between qt 5.4.1 to 5.5.0.

To answer my question as to whether I can assume that the lock file extension is ".lock", look at QConfFileSettingsPrivate::syncConfFile:

http://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/io/qsettings.cpp#…

where it appends ".lock" to settings filename when creating a temporary lock while syncing settings. So this hopefully answers the question "Where did this .lock file come from?" It seems Qt is taking care of the necessary locking when modifying the settings.

I don't see anything in qsettings.cpp that leads me to think this lock file is linux-specific, so I think we can assume that mac and windows also create this settings lock file with extension ".lock" temporarily when modifying the qsettings (we just don't see it cause it is created and destroyed so fast, so we never knew about it).

Opps...posted to wrong forum topic. I've reposed to seperate topic: https://musescore.org/en/node/75561