Quote:
Originally Posted by KevinH
That is good. I have been reading up on how Windows handles disk based web caches. It seems Windows has a special security feature that marks everything in the web cache folder and the folder itself (that can be accessed across multiple threads) as not being executable ever. That makes good sense for a web cache. But a folder needs executable permission to write or change any files in it.
So each instance keeps a list of its own cache folders and gives its webengine process permission to write it it. So clearing a cache folder from one external process that does not have the needed permission will fail. This is something specific to Windows.
I think clearing the cache silently was ignored for any process without permission in older Qt/Sigil but since Qt 6.7 we need to wait for the cleared done signal which revealed the problem.
MacOS shares a single cache across multiple mainwindows all part of the same process, so no problems.
|
My Windows user has full permissions to the location where we were writing our cache files in Sigil's prefs directory: C:/Users/<USER>/AppData/Local/sigil-ebook/sigil/
I'll have to fire up an older build and see if that holds true for the cache directories that the qtwebengine process was creating there previously.
Quote:
Originally Posted by KevinH
I have no idea how it works with Linux and multiple instances of Sigil. Perhaps all QtWebEngine processes share the same group and can access any cache?
I also have no idea how a new process takes ownership of an existing web cache. The new QWebEngineProfileBuilder forces unique names so how on earth can they take ownership of a web cache that already exists (the whole point of disk caches) even when there is only one instance of the app running.
We ended up wiping all disk caches out to prevent folder proliferation.
|
Not sure. I'd have to be home to check, but maybe suid or sgid or sticky-bit applies to the cache files created by qtwebengineprocess?