FileUtils::dirname() did not include the drive letter under Windows and
the return value of dirname() was fed directly to mkpath().
When the drive letter is not specified, mkdir() assumes drive C: -
this either fails if the user does not have access rights to drive C:
or creates a directory in the wrong place.
This commit changes FileUtils::dirname() to include the drive letter
on Windows and adds a test.
Under Debian, the libbz2.so SONAME is libbz2.so.1.0, so ld links to this
version of libbz2. Debian has symlinks from libbz2.so.1 and libbz2.so.1.0 to
libbz2.so.1.0.x. RedHat however does not have the libbz2.so.1.0 symlink
so linking fails at runtime.
This commit fixes the problem by linking to libbz2 statically on Linux.
This does not bloat the updater library too much as libbz2 is only 70K
(measured on Ubuntu 11.04).
It appears that the previous fix was incorrect. The issue was
not with the current directory used by the process but that
the executable path passed to CreateProcess() used forward
slashes instead of back slashes. A runtime error in loading
the WinSxS DLLs (the C++ runtime library) resulted.
Although most Windows API functions both back and forward slashes,
this appears not to be the case for loading of side-by-side
DLLs from the application's directory under Windows XP.
This may be related to the LoadLibrary() function whose documentation
specifies that backslashes must be used instead of forward slashes.
This commit converts the executable path to use backslashes before passing
it to CreateProcess() and removes the previous change to alter the
current working directory before starting the main app binary.
* Remove accidentally added LOG() call which referenced the Unix-only EROFS constant
* Rename 'errno' parameter to 'errorCode' so that it does not conflict with the macro of the same name.
This allows the updater to work on older Windows XP systems
without the VC++ 2008 runtime redistributable installed.
* Add statically linked pre-built versions of the zlib and
bzip2 libraries.
This increases the size of the updater executable by 200KB
to ~400KB on Windows.
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.
