Running the updater binary under a debugger makes it easier to attach to the process
and set breakpoints in GDB than trying to start the ruby script itself under GDB and
follow forks until the updater executes.
On Mac, this can happen if the user runs the app directly from a disk image. On all platforms,
this can happen if the app is run from any kind of read-only media or network share.
* Intercept IO errors during installation and try to find a more friendly alternative
to the OS error string.
* Catch any IO exceptions throw whilst reverting a partial update and log details.
* The WAIT_FAILED error enum value in ProcessUtils.h conflicted
with Win32 API #define names - use CapitalCase enum names
instead.
* Add dummy return value for Windows implementation of FileUtils::fileMode()
Previously the application was run from outside a bundle and hence did not
have an app icon - so OS X displayed the generic 'terminal' icon in the elevation
dialog. The app icon in the dock was set at runtime, but disappeared temporarily
on shutdown when the overridden app icon was replaced with the default icon.
This commit fixes the problem by detecting whether the executable is being
run from within a bundle and if not, creating a minimal app bundle in /tmp
and re-launching the updater from there.
* Use WEXITSTATUS() to correctly extract the exit status from the 'status'
value returned by waitpid(). ProcessUtils::runSync() returns a signed value
so an exit code of -1 would be returned rather than 255.
* If ProcessUtils::runSync() cannot launch the child process (eg. because the binary
does not exist), return an exit status that does not conflict with the exit statuses
used by the sudo front-ends to indicate failed or canceled authentication.
This alloes runElevatedLinux() to fall back to the next sudo binary only if starting
the sudo front-end failed.
* Add documentation on the different behaviors of kdesudo and gksudo with
respect to exit codes if elevation fails.
* Improve the description of the task that appears in the GTK sudo front-end. The application
is now described just as 'Mendeley Updater' instead of showing the whole command.
* Only try to use kdesudo in KDE environments, use gksudo otherwise.
Under Linux we have control over how the process requesting elevation
describes itself - use this to refer to the updater as 'Mendeley Updater'
rather than 'updater'.
* In addition to creating symlinks and installing files from .zip packages, support
copying uncompressed files from the root of the package directory to the installation
path.
This is required for installing new versions of the updater itself which is downloaded
uncompressed to the package installation directory.
* Replace use of File.absolute_path with File.expand_path for compatibility with Ruby 1.8.7
* Modify updater test to test installation of the updater binary to the install directory.
* Use the same argument quoting logic when launching both elevated
and non-elevated processes under Windows
* Include the executable name in the command-line when launching
a non-elevated process. Previously the child updater.exe process
was receiving the '--install-dir' option name in argv[0] and ignoring
it because it was only looking in argv[1..N-1]
* Change the install path in the updater test to include a space.
TEST: Ran test-update.rb with space in test install directory
under elevated/non-elevated cases.
The project is BSD licensed, but the Mendeley logo graphics / names
are trademarks of Mendeley Ltd. and will need to be replaced if this tool
is re-used in other projects.
The version of zip on Mac OS 10.6 is >= 3.0 but was not
compiled with bzip2 support.
This test tries to create an empty zip archive with bzip2 compression
and then checks the error message reported.
On platforms where the zip tool does not support bzip2, the updater
will still support decompression of bzip2 .zip files because
the updater uses a separate library for zip decompression.
Looking at some of my test systems:
* Mac OS 10.5's 'zip' lacks bzip2
* Mac OS 10.6's 'zip' supports bzip2
* Debian Lenny's 'zip' lacks bzip2
* On Windows it depends what version of cygwin is being used. The version we are currently
using on build-windows (zip 3.0) supports bzip2.
In brief testing, this reduced the file size of an all-in-one zip package
by several MB. Provided that the zip library can support bzip2 decompression
on all platforms, this would be an easy win to reduce download sizes.
The use of QFile::Permission flag values is a legacy from the old Qt-based updater.
Unix chmod values are used by the native system calls so it makes more sense
to use them instead.
* Update the test examples and the test update script.
* Update the package building tool to populate the permissions field with octal chmod values.
* Re-organize the sections into a more logical order.
* Tidy-up the wording of the introduction.
* Add more details to the section on customizing the updater
Add a VERSION_INFO section to the executable's resource file specifying
the product name and description.
The organization is currently set as 'Mendeley Ltd' - other projects
will want to customize this.
When the produced executable is digitally signed, the product name
and description are shown in the UAC prompt asking for admin
permissions.
Mendeley Desktop <= 1.0 clients pass a relative path for the script argument but
run the updater from the directory containing the main application binary instead
of the package dir. The script argument, if relative, is therefore treated as
relative to the package directory.
Mendeley Desktop <= 1.0 clients set CurrentDir to the directory containing the main
application binary rather than the root of the install directory.
Change the parsing in UpdaterOptions and adjust the test accordingly.
The updater binary is listed as a package on its own but is not
compressed. The program downloading the update can then download
all packages for the new version including the updater executable
'package' (in reality, just the plain file) and then invoke that updater.
This also allows for substitution of the updater binary with a different
version via the -u parameter.
* Abort if running the zip tool fails
* Abort if multiple file path rules match a given file
* Remove part of the special updater binary handling - this needs to be reworked
* Sort the file paths before feeding them to the zip tool, so that multiple runs with
with the same set of files will generate the same packages
These specify the target version for the update and the platform and are embedded
in the <targetVersion> and <platform> elements of the generated file_list.xml file
Ordinarily the script will use the updater binary from the input files directory which
matches the path of the updater binary specified in the package config file.
However it may sometimes be necessary to use a different binary, which can be done
via a -u option.
