Quote:
This discussion has convinced me to start using this functionality of Sigil. What can I say except WOW!
Then, I ran across the problem under discussion. In that case, I had four instances of Sigil running, four different files, of course. When I opened the fourth one, my saved searches disappeared from the first three instances, while remaining in the fourth.
So, I closed everything down, then called up four blank instances of Sigil. Opened the first file, everything was fine. Opened the second file, bye-bye saved searches.
Okay, shut everything down again. Open an instance of Sigil. Open my first file. All good. Open a second instance of Sigil. Open the second file. Everything still good. Rinse and repeat for the third and fourth instances, and saved searches remained in all four instances.
This is on a machine running a (rather old) install of Windows 7 64-bit, which has never been connected to the internet, so whatever QT came "out of the box" is what it is using now.
Anyway, FWIW, I hope this helps you to track down this very elusive anomaly.
|
Thanks for testing the bug and demonstrating it. Because this bug can not be reproduced on Linux or Macintosh, the source of the bug is almost certainly in Qt itself and has to do with inter (across) process file locking. Unfortunately, all we can do is create a bug report on Qt which if past bug reports on Qt are any indication, will simply be ignored for years.
We can try to create a platform specific workaround for this, but OS level inter-process file locking on Windows is really a black box to me. I guess, we could duplicate the clips.ini file itself with every launch into a temp space and then point each process to its own copy, but that seems a bit overkill. Read-only file locking should not be an issue unless something is in the process of writing to the clips ini file but as far as we know, that does not happen until we close the preferences.
KevinH