| Age | Commit message (Collapse) | Author |
|---|
|
If a path was given as ONLY 'ebin' and not for example './ebin', then
systools:make_tar would fail with a function_clause exception in
filename:join/1. The bug was in systools_make:appDir/1, which tried to
find the parent directory of the given path. This function now uses
library functions filename:basename and filename:dirname instead of
general list manipulations.
|
|
Given this option, all modules that are to be purged by indicated
upgrade,and that can be soft purged, will be purged when all other
check of check_install_release have been successfully completed.
I added a note under install_release in the reference manual about how
to use check_install_release with this new option in order to speed up
the execution of install_release.
I also added three more test cases for this functionality.
|
|
This commit utilizes the new bif erlang:check_old_code/1 to check if a
module has old code in the system or not before running
erlang:check_process_code/2. This is to optimize
release_handler:install_release (and
release_handler:check_install_release).
A new test is added which checks that after traversing all
processes/modules once and purging all old code, the second run
through this part of the code is "sufficiently" much faster.
A note is also added in the reference manual for
release_handler:install_release about how to go around the efficiency
problem of this function.
|
|
* hw/update-chmod-without-f:
Again: Call chmod without the "-f" flag
OTP-9491
|
|
The appup instruction 'delete_module' would cause a crash during
upgrade if the module to be deleted was not loaded. The reason was
that the release_handler tried to read the version number of the old
module after the code path had changed to point to the new version of
the application. Thus, if the module had not been loaded before the
upgrade, there would no longer be any such module in the path
(delete_module indicates that the module is deleted from the new
version of the application).
This is corrected by letting the release_handler read the old version
of the module only if the module is updated - not if it is
removed. And it is always read before the code path is changed.
|
|
If a new version of an application did not include any erlang module
changes, the code path of the application was not updasted unless a
'load_object_code' instruction was added for the application. This
would be a problem if e.g. only some files in the priv dir were
changed, since calls to code:lib_dir or code:priv_dir would then point
to the old location of the application. This has been corrected - now
code:replace_path/2 will be called for all applications that are
changed (i.e. when the application's vsn is changed in the .rel file).
|
|
The service will automatically use the start_erl.exe from the same
directory as erlsrv.exe, and heart will use $PATH, which will
always have the erts bin dir first. The reason is to avoid using old
executables after upgrading erts via the release_handler.
|
|
This commit adds test cases from release_handler_SUITE on windows,
including some corrections in erlsrv and release_handler.
|
|
Commit 7ed11a886fc8fcaf3c2b8324294e2f24e02b0f28 removed the "-f" flag
from chmod calls in Makefiles:
| "-f" is a non-standard chmod option which at least SGI IRIX and HP UX
| do not support. As the only effect of the "-f" flag is to suppress
| warning messages, it can be safely omitted.
Meanwhile, new "chmod -f" calls have been added. This commit removes the
"-f" flag from those new calls.
|
|
|
