Since my last report, I've done less work than usual (I was away on holiday in 13-18 and then took a while to get back to my normal capacity). I know that this report is required to be big, but there really isn't all that much new information that I can add here. My midterm evaluation explained many of the the details and there's no point on repeating the same things again.
If you want a more detailed report, please consult Midterm report.
Since my last report, I have made fixes as well as implemented new things. sci_download_updates is now fully capable of querying the server, downloading the .tar(.gz) file and decompressing it into a temporary folder, then writing the path to the temporary folder into the unapplied updates file (discussed below).
The code has suffered a lot of refactoring (the directory structure of src/cpp changed, libcommon's files were refactored etc.).
After finishing with sci_download_updates, all the bug fixing and refactoring, I have continued working on the application that applies the updates, and this is the new part that I would like to discuss further.
First of all, we are now using a file to record all the updates that have been downloaded. On Windows, this file is stored somewhere in APPDATA\Scilab\_scilab_version_\unapplied_updates.txt. On POSIX, this file will be in /var/lib/scilab/unapplied_updates (if it's installed, otherwise SCI/unapplied_updates).
The first line of this file is the letter Y or N, indicating whether the unapplied updates are scheduled to be applied or not. The following lines each indicate the path to a temp directory where updates have been extracted (each of those folders were created via sci_download_updates).
Whenever sci_download_updates successfully downloads and extracts an update to a temporary folder, it automatically appends the path of the temp folder to the unapplied updates file. When sci_apply_downloaded_updates is called, the N is changed into a Y in the unapplied updates file.
Now, when Scilab is closed or started, it verifies if the first line of the unapplied updates file is an Y and if there are any updates to apply. If this is the case, then the update_applier binary is started and scilab closes itself.
If the unapplied updates file cannot be opened for reading by scilab, then this means that we are currently in the process of applying an update (and the lock is held by update_applier), so scilab refuses to start.
When update_applier is called, it attempts to gain exclusive lock of the unapplied updates file, as well as the required permissions to overwrite scilab files. If any of this fails, it starts scilab back and then exits.
Otherwise, it takes each folder which contains an update, and for each of them, it patches, one by one, all the files that need to be patched by that update. In case the computer crashes or anything else falls apart, update resuming is supported by storing a stage.txt file for each update, indicating how many of the files were patched, so that update_applier knows where it should continue.
As soon as an update is applied completely, it is removed from unapplied updates file. When all the updates are removed from the file, update_applier finishes executing and restarts scilab.
There are a few issues that need to be resolved one way or another:
- update_applier is not a library, but an application, so we can't use scilab's toolbox builder to build it. And there might be problems with shipping it already built, since update_applier links with stuff created by scilab's toolbox builder (like libcommon). Although those are dynamically linked and we only use the .lib file, so this might be fine.
- update_applier has to run it as administrator (Windows) and root (Linux, if the app is installed)
- Multiple installations of scilab can end up mistakenly using the same unapplied_updates.txt file. We need some install id so we can uniquely identify different scilab installations.
- Maybe we should use a designated folder instead of a temp folder in the future (for storing scilab updates), since temp folders can be erased at unexpected times.
- The above procedure requires not only work on the toolbox, but also adding code directly into Scilab.
- We should have a sci_apply_downloaded_updates_now, which closes scilab immediately to apply the updates. Also, we should have an argument that can be used on starting scilab to prevent it from attempting to apply updates.
Planned work in the next week
As can be seen on the roadmap (on the midterm report), there are still things that need to be done. I am now planning to make sure everything works with update_applier (some testing), then I'll start work on multithreading (spawning a separate thread which periodically checks for updates and downloads them, depending on configuration).
After this next week, I'll have to work on cross-platform-ness more, because some things work fine on Windows but are untested on POSIX.