- ContentManager::m_knownZimFiles[dirPath] now stores filenames (rather
than full paths) of known ZIM files in directory at dirPath.
- Library::getLibraryZimsFromDir() returns a set of file names (rather
than paths)
Note that the change of the semantics of ContentManager::m_knownZimFiles
has been carried out via the change in the value of the second argument
of ContentManager::setMonitorDirZims():
1. In KiwixApp::setupDirectoryMonitoring() the latter is fed with the
output of (the now changed) Library::getLibraryZimsFromDir()
2. In ContentManager::updateLibraryFromDir() all variables representing
a set of files now contain filenames only (note that
ContentManager::handleNewZimFiles() returns just a subset of its second
parameter) and therefore produce a set of filenames.
Before this change, once a ZIM file was detected in a monitored
directory it could slip into the known ZIM file list even if it was
a partially downloaded ZIM file that failed to be added to the library.
This happens when another valid/healthy ZIM file is added to the
monitored directory or a known ZIM file is removed from it (the bad
ZIM file is included in the update triggered by the other ZIM file).
Now ZIM files that failed to be added to the library are NOT inserted
in the list of known ZIM files and thus will be reevaluated for every
change in the monitored directory. Thus a file being downloaded by an
external tool will eventually be successfully added to the library
(since updates to the file should trigger an update to the directory due
to the changed modification time of the file).
This however may result in excessive CPU usage in the following
scenario. Suppose that there are a number of partially downloaded files.
Only one of them is being downloaded, while the others are paused. Every
time the next chunk of data is written to that active file, directory
monitoring will try to add *all of* those partial ZIM files.
There are two optimizations against such waste of CPU cycles:
1. Only try to add those files that had their modification
time changed since the previous attempt.
2. Debounce the updates (react to updates, for example, at most once per
second).
Those optimizations will come next.
On Windows, static libraries are using "foo.lib" naming.
On Unix, they are in the form of "libfoo.a"
On Windows, "foo.lib" can also the definition of symbols in a foo.dll.
So you can link to "foo.lib", whatever you are doing static or dynamic linking and you are good.
However, meson is always creating static library as "libfoo.a"
'to avoid a potential name clash with shared libraries which also generate import libraries with a lib suffix.' [1]
On top of that, qmake is replacing all `-lfoo` in LIBS by `foo.lib` (on Windows).
So at the end, we try to link with `foo.lib` but we have `libfoo.a`
Solution could be :
- Rename `libfoo.a` to `foo.lib`, but it would mean modify deps libraries on the FS
- Don't use LIBS and directly set QMAKE_LFLAGS but we would have to handle different command line option format
between g++/clang and msvc
- Update meson build system of each projet to explicitly set the library naming.
- Replace `-lfoo` with absolute path to static library. This is what meson is doing internally and what
we are doing here
Any `-lfoo` is replace with absolute path to static library (`libfoo.a`) if we found one.
Else, it is keep unchanged.
[1] https://mesonbuild.com/Reference-manual_functions.html#library_name_suffix
When trying to display resources from an invalid ZIM file that fail to
be retrieved due to problems with the ZIM data, now an HTML error
page is returned instead. Note that the resource being accessed
may in fact be an image, a CSS or a javascript file and the user may not see
the error (though the appearance of the webpage trying to load and use
that resource will be affected to various degrees).
