Invoke [NSApp stop:] on the main thread. When invoked from
UpdateDialogCocoa::updateFinished() on the background thread
it had no effect as [NSApp stop:] only stops the current run loop.
* Add a test which runs the test-update.rb script
* Add a --auto-close option to the updater which auto-dismisses the
update dialog once installation is complete. This is used in
test-update.rb to make the script run without user interaction
being required.
MD-19678 #time 1h
Add an UpdateDialog base class which the different platform
implmentations implement and use this to:
* Remove the duplicated runWithUi() functions in main.cpp
* Reduce the amount of boilerplate for loading the GTK dialog at
runtime and falling back to the non-GTK 'dialog' if this fails.
MD-19678 #time 1h
* Remove the CMAKE_OSX_DEPLOYMENT_TARGET setting and just
rely on the -mmacosx-min-version argument.
* Avoid requiring a specific OS X SDK version - just use the
default one.
On Mac, this is important as TMPDIR points to a user-specific temp dir
which avoids a potential problem where an app bundle created in the temp dir
running as User A cannot later be replaced by a copy of the updater running
as User B.
MD-19088 #time 30m
Reviewed-by: Nicolas Esteves
FileUtils.ln_s() is not supported on Windows and the updater
doesn't support symlinks on Windows either.
Create a dummy 'real' file to uninstall instead.
MD-19006
When checking whether a file exists before uninstalling it, FileUtils::fileExists()
checked whether the link target existed instead of the link itself. Change fileExists()
to use lstat() instead of stat().
The updater uninstalls files in the order they are listed, if a file and a symlink to it
are both being uninstalled (eg. libMendeley.so.1.6.0 and the symlink libMendeley.so.1.6)
and the real file is removed first, uninstalling the symlink later failed due to the
above issue with uninstalling broken symlinks.
MD-19006
Copy the work-around for missing template symbols in the C++ runtime library
from Mendeley Desktop.
See the StackOverflow discussion referenced in the comment for more details.
Reviewed-by: Carles Pina
Compare the package source dir and the post-update install dir recursively and check:
* There are no unexpected files in the install dir
* All files in the packaging dir were installed with the correct permissions and content
MD-18896
Reviewed-by: Carles Pina
If an update includes a new file 'dir1/dir2/file' where neither 'dir1' nor 'dir2'
already exist, the update fails as it attempts to create 'dir2' without first creating 'dir1'.
Use mkpath() instead of mkdir() to create the dest dir for a file.
MD-18896
Reviewed-by: Carles Pina
* Change the default SDK from OS X 10.6 to 10.7.
The 10.6 SDK is no longer bundled with the current version of XCode
* Add explicit casts for permissions value
MD-18896
Reviewed-by: Carles Pina
CMAKE_OSX_DEPLOYMENT_TARGET sets the minimum version that we want the app to run on,
CMAKE_OSX_SDK is the name of the SDK which we want to build against.
The OS X 10.5 SDK does not exist when building on OS X 10.7,
so allow this to be set to 10.6 instead.
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.
