Apple Update Traps
If an update fails and you need to re-install packages, be aware that many installers will fail to re-install unless you delete the package first. This is because many Apple installation packages check the date of any existing files and simply leave them in place if the target machine's files are dated later than the installation files.
As an example, the OS-X update to 10.3.9 broke my Java installation so that running Java gave a 'segmentation fault'. When I found the Java installation kit and installed it, the installation appeared to work but the fault remained.
Checking the dates on the files in the directory that holds the main Java executable (/System/Library/Frameworks/JavaVM.framework/Commands) quickly revealed what was going on...
This problem can be assumed to apply to any installation that relies on existing files having a date earlier than its own. If you have to re-install after a failed update this will, almost certainly, not be the case, so beware!
If an update fails and you need to re-install packages, be aware that many installers will fail to re-install unless you delete the package first. This is because many Apple installation packages check the date of any existing files and simply leave them in place if the target machine's files are dated later than the installation files.
As an example, the OS-X update to 10.3.9 broke my Java installation so that running Java gave a 'segmentation fault'. When I found the Java installation kit and installed it, the installation appeared to work but the fault remained.
Checking the dates on the files in the directory that holds the main Java executable (/System/Library/Frameworks/JavaVM.framework/Commands) quickly revealed what was going on...
-rwxr-xr-x 1 root wheel 61236 16 Apr 22:28 appletviewerThe time-stamp on the files was the date of the update. Deleting the Java Framework directories (rm -d /System/Library/Frameworks/Java*/*) and re-running the installation routine fixed the problem.
-rwxr-xr-x 1 root wheel 61236 16 Apr 22:28 extcheck
-rwxr-xr-x 1 root wheel 61236 16 Apr 22:28 idlj
-rwxr-xr-x 1 root wheel 61236 16 Apr 22:28 jar
-rwxr-xr-x 1 root wheel 61236 16 Apr 22:28 jarsigner
-rwxr-xr-x 1 root wheel 61236 16 Apr 22:28 java
-rwxr-xr-x 1 root wheel 2126 1 Sep 2004 java-rmi.cgi
-rwxr-xr-x 1 root wheel 61236 16 Apr 22:28 javac
-rwxr-xr-x 1 root wheel 61236 16 Apr 22:28 javadoc
-rwxr-xr-x 1 root wheel 61236 16 Apr 22:28 javah
-rwxr-xr-x 1 root wheel 61236 16 Apr 22:28 javap
-rwxr-xr-x 1 root wheel 61236 16 Apr 22:28 jdb
-rwxr-xr-x 1 root wheel 61236 16 Apr 22:28 keytool
-rwxr-xr-x 1 root wheel 61236 16 Apr 22:28 native2ascii
-rwxr-xr-x 1 root wheel 61236 16 Apr 22:28 orbd
-rwxr-xr-x 1 root wheel 61236 16 Apr 22:28 policytool
-rwxr-xr-x 1 root wheel 61236 16 Apr 22:28 rmic
-rwxr-xr-x 1 root wheel 61236 16 Apr 22:28 rmid
-rwxr-xr-x 1 root wheel 61236 16 Apr 22:28 rmiregistry
-rwxr-xr-x 1 root wheel 61236 16 Apr 22:28 serialver
-rwxr-xr-x 1 root wheel 61236 16 Apr 22:28 servertool
-rwxr-xr-x 1 root wheel 61236 16 Apr 22:28 tnameserv
This problem can be assumed to apply to any installation that relies on existing files having a date earlier than its own. If you have to re-install after a failed update this will, almost certainly, not be the case, so beware!
Learn
more by searching Google here...