Mac OS X contains built-in scripts which perform specific maintenance operations automatically on a predefined schedule. Some third-party applications (e.g. virus scanners) also add their own maintenance scripts to the script suite provided by Apple. Three different script sets are available:
The scripts are a historic component of Mac OS X. They were originally important for users who operated their systems on a 24/7 basis, typically as servers. Today, nearly all tasks of the scripts have been superseded by other service processes automatically running in Mac OS X. So it is not really important that you run the scripts.
Nevertheless, TinkerTool System gives you the opportunity to run the scripts manually, at times where the administrator feels it is right. The item Periodic Tasks in TinkerTool System can be used to run a script set or all three script sets “now” by just pressing a button.
It is one of the Mac OS X myths that the operating system would automatically reschedule, postpone or make up the periodic tasks at times when the system is idle, in case the computer was switched off at the scheduled time. This is not true although many Internet pages claim the opposite. The truth is: Mac OS X will automatically make up a scheduled task at a later time if the computer was switched on but in sleep mode at the time the original action was planned. However, the scripts will not run at all if the computer was shut down at these times.
Apple has changed this policy for OS X Mavericks: With OS X 10.9 or later, the operating system indeed reschedules the periodic tasks, ensuring they run at a time when your computer is powered on. For this reason, it is possible but usually not necessary to use this feature with OS X Mavericks.
You can run the scripts manually if you need their features immediately. TinkerTool System displays the three script categories in a table, together with times and dates when the script sets have run last, and buttons to open reports for each of the respective sets. To run one or all script sets, perform the following steps:
The reports, which can be opened via the buttons labeled Open…, are plain text files containing diagnostic output recorded directly by the different script sets. TinkerTool System does not interpret or process the contents in any way. Apple’s scripts or the scripts of third-party vendors are solely responsible for the reports.
Each single file and folder of your computer is stored with additional attributes. Among those attributes are the permission settings that control which users or user groups are allowed to perform certain operations with the objects, for example reading, writing or deleting a file. After Mac OS X has been installed on a computer for the first time, either at the factory or by yourself, all operating system files and folders have exactly defined permission settings, which are necessary for the system to operate correctly. Some files should have special protection. For example mail databases and print queues should always be kept confidential. Other objects need to be open for everyone: Specific background services of the system run intentionally with “under-privileged” user accounts, for example, which ensures that even in cases where such a service has been successfully hijacked by a hacker, this security breach cannot be used to gain access to any higher-level operations or files. However, even these under-privileged services must have permission to read their own program files, so if an administrator mistakenly removes “read permission for everyone” in a system folder, this can make large parts of the base operating system unusable.
To repair the system, in case the permissions of important system files have been altered erroneously, Mac OS X contains a reset feature which can restore the permission settings for each of the operating system files back to their individual factory defaults. This is useful to recover from user errors outlined in the last paragraph. It can also be necessary to reset permissions after you have used defective or badly written installation software which might have misused its installation rights to modify permissions of operating system files in an inappropriate way.
Apple uses the term “repair permissions” which gives some users the wrong impression that permission settings could “deteriorate” or “break” somehow. However, permissions never change themselves and cannot get lost. Only administrators and the programs they launch can intentionally or inadvertently change permissions by explicitly altering the settings. For this reason, TinkerTool System uses the more exact term “reset permissions”.
The feature to reset permissions will only affect files and folders which belong to the operating system, and is additionally restricted to files which won’t have their permissions changed as part of normal operations. It will never touch any user files because the system cannot “know” the intended permission settings for your personal data. It would be a major security problem if the system flagged some of your files as being “readable by everyone” when you actually wanted them to be kept top secret, only readable by your own user account.
Mac OS X determines the correct default permission settings for its own files by reading its installation database which is kept in the folder /var/db/receipts. If you have accidentally deleted the contents of this folder, the reset feature and specific software update features will no longer work and the system will have to be reinstalled.
To let Mac OS X reset permissions of the running operating system version, perform the following steps:
A complete run will need several minutes. TinkerTool System will collect all notification and error messages of the reset procedure in a report window. Note that all messages are defined and created by the Mac OS X version you are using. TinkerTool System does not interpret or process these messages, nor does it execute the reset procedure itself.
When using specific versions of Mac OS X, the reset feature may list many notification messages even if all permission settings are set correctly. Some of the messages may sound alarming to unexperienced users and may be misinterpreted as errors. Although the messages are correct, they are usually no cause for concern. For detailed information which messages are “normal”, please open the context help drawer of the Permissions feature and click on the link to Apple’s documentation, listed at the end of the help text. The web page should give you up-to-date information which messages you can safely ignore in current operating system versions and which not.
All applications you are launching are dependent on services of the operating system: The programs are using features of the system, for example to receive click messages from the mouse, or to open windows on the screen. Technically seen, this means that each application has to link its own program code with the code libraries of the operating system. Programs typically use several thousand functions available in the system which have to be “located” while the application is starting. These locations, namely the file paths where the code libraries are stored, and the exact byte positions within the libraries are not necessarily fixed: They may change from OS version to OS version, so the applications have to do a lot of work checking and locating all these OS functions at launch time.
Applications try to accelerate this link process at start time by assuming that the code locations remain constant as long as no new operating system updates have been installed since the last launch. They store the required code locations of functions of the operating system into a cache area in their own program codes. So the next time the application is being launched, it can simply reuse this saved information and does not need to repeat the whole search process of locating OS functions. The cache only needs to be rebuilt if the application detects that new system libraries have been installed.
This optimization technique is called prebinding. It only speeds up the launch time of programs. Prebinding does not accelerate the programs themselves. This technique is not restricted to applications only. It is even more important for the system libraries themselves, because they are also using each others functions. For example, the library drawing windows on screen uses features of the graphics library, and the graphics library uses functions of the system kernel. For this reason, code libraries and similar software components, like plug-ins, make use of prebinding, too, although they don’t really have a “startup phase”.
As mentioned in the last paragraphs, each application “re-prebinds” itself to the available libraries when it detects that new libraries have been installed, for example as part of an OS update. In order to anticipate this step, it is a good idea if an upgrade installer simply tells all applications on the computer to re-prebind themselves during, or more exact, just after the update has been installed. The Mac OS X Installer indeed performs this step as last part of each system update. It is done when the messages “Optimizing system for software” or “Optimizing system performance” are being displayed.
It is one of the Mac OS X myths that, as of Mac OS X 10.4 or later, the system would no longer use any kind of prebinding. This is not true although many Internet pages claim the opposite. The truth is: Mac OS X 10.4 Tiger and later system versions indeed use a new improved linking system which eliminates the need of prebinding for applications and third-party code libraries. But system libraries are still prebound, however, and they benefit from this optimization.
This means if a system update installation was interrupted somehow, or if you manipulated one of the system libraries, for example by “downgrading” a specific library via a Time Machine backup, all prebinding information in the system should be updated. To manually start a system-wide prebinding process, perform the following steps:
Mac OS X contains a background service which communicates with the directory services configured for your system. This service is the central information broker needed to collect data about users, computers, IP addresses, user groups and many other things relevant to an operating system. Under special circumstances, the internal memory contents of this service may contain incorrect or outdated information, especially if your computer is accessing a DNS server or directory server which doesn’t work reliably, or if the network configuration has changed abruptly. This can result in unexpected delays (spinning rainbow cursor) especially when using network functions.
In this situation, clearing the online cache of directory services might correct the problem: The information broker will begin with fresh new data it fetches from your network and the local computer. Note that this cache is not stored in any file. It is kept in the online memory of the directory services subsystem of Mac OS X.
The word “directory” is sometimes used as a technical term for a folder storing files. This is not what is meant here. In this context, the word directory refers to an inventory list of names, objects and network addresses relevant to your computer. Mac OS X is always running a directory service no matter if the computer is connected to a network or not.
To clear the directory cache of Mac OS X, perform the following steps:
Because Mac OS X is a BSD UNIX system, it comes with the program “locate”, a command-line application to quickly find files by their names or parts of their names. Locate is usually faster than Spotlight when searching for names and does not distinguish between visible and invisible files. Similar to Spotlight, locate needs an internal database to do its job. This database is updated in regular intervals to ensure that the program has up-to-date information about new and deleted files.
In operating system versions prior to 10.6, updating the locate database was part of the periodic tasks mentioned at the beginning of this chapter. From then on, Apple removed this job from the periodic scripts. It can now be controlled independently, and is switched off by default, because most users don’t work with Mac OS X command-line programs. Checking whether the service to update the locate database is currently on or off is an information available to administrative users only. Perform the following steps to see if the update service is active or not:
The current state will now be displayed by the check mark at Mac OS X should update the locate database periodically. You can now either set the check mark to activate automatic maintenance of the database, or remove the check mark to shut down this service.
In a default installation of Mac OS X, the system will update the locate database automatically each Saturday at 3:15 a.m. If your computer is neither on, nor in sleep mode at that time, the update will never take place. To enforce an immediate update of the locate database “now”, press the button Update database now.