A file system link is an additional representation of an existing file, or —in some cases— a folder. It can be used to refer to the file at a different location, in another folder or on another disk drive, or by using a different name. macOS is supporting three different types of links:
The macOS Finder can create aliases only. If the Finder displays a symbolic link, it will also represent it as alias to simplify the situation for unexperienced users. Such objects are shown with a black curved arrow in addition to their icons. Aliases are a technology taken over from the classic Mac OS, and in some specific cases, applications must explicitly support the alias technology in order to access the original item the alias is pointing to. Links however are evaluated by the operating system itself, so they should work with any application.
In fact, modern versions of macOS internally differentiate between classic Mac OS aliases, which are now deprecated, and modern aliases based on so-called bookmarks.
Because the Finder cannot create symbolic links or hard links, TinkerTool System adds these missing functions. Perform the following steps to create links:
macOS supports a special protection attribute which can be attached to files or folders. When you mark an object as being protected, it is no longer possible to change or delete it. Any change requires that the protection is being removed first. The macOS Finder uses a lock symbol displayed in addition to the usual icon to represent a protected object. Sometimes, the terms “locked” and “unlocked” are used for protected and unprotected objects, respectively. However, locking can also mean a different thing, namely to mark an object as being in exclusive use by a program, so we don’t use this term to avoid confusion.
TinkerTool System has the option to set or remove protection flags not only for single objects but for a whole hierarchy of files and folders included in a top folder. To work with protection attributes, perform the following steps:
Some non-Macintosh file systems are not capable of supporting protection attributes. In this case, the operating system may confirm that the protection marker has been set successfully, but the object remains in the unprotected state.
In addition to the protection marker, which is also supported at the UNIX level of macOS, the operating system is supporting some high-level attributes which have been adopted from the classic Mac OS.
Although we are referring to type and creator attributes as being HFS codes, these codes are not restricted to be used on HFS and HFS+ file systems only. macOS is capable of emulating these attributes on nearly any file system.
To change one or all of these high-level attributes, perform the following steps:
Type codes and creator codes must be specified either by four characters of the ASCII character set, or by four arbitrary bytes which have to be entered using eight hexadecimal digits (the digits 0 to 9 and the letters a, b, c, d, e, f, or A, B, C, D, E, F). The program will automatically detect what you mean depending on the length of your input. Note that codes specified by ASCII are always case-sensitive. Examples for valid codes are:
To remove a type or creator code from a file, delete the entry in the respective code field completely and click Apply. TinkerTool System cannot assist you in selecting type or creator codes for known document types or known applications, respectively. You’ll have to know the correct codes in advance.
Although it is technically possible to store HFS type attributes for folders, the meaning of this was undefined in the classic Mac OS, and Apple never supported this officially. For this reason, TinkerTool System also won’t permit to attach these attributes to folders.
Keep in mind that you can no longer use drag-and-drop or file dialogs for objects which are invisible. You’ll have to enter the object’s full UNIX path to access it by an application. This also includes TinkerTool System. However, you could use its sister application TinkerTool to modify your Finder preferences to the effect that the Finder displays invisible objects, too.
An important part of the security infrastructure built into macOS is its capability to track potentially dangerous files coming from untrusted sources, or having been transferred via unsafe channels like the Internet. When you open such a file or program, you will receive a warning message which asks for reconfirmation whether you actually trust the file. The source of the file and the time when it was loaded onto your computer is noted in the message.
This feature is technically implemented by adding special quarantine attributes to the affected files. TinkerTool System can display this information, giving you the option to remove the attribute, hereby “un-quarantining” the files. This can be helpful if you know that the file comes from a trusted source and you like to “re-publish” it on your own computer, for example before placing it into the public folder /Users/Shared or before uploading it to your local file server. This way you can avoid that other users are confronted with the warning message. They might not be able to successfully confirm they trust the files because they might not have the necessary write permissions for the shared folder.
Removing quarantine information from an application will also disable the security feature “Gatekeeper” for that program. macOS will no longer recognize that the application has been downloaded from the Internet, so its files will become irrelevant to Gatekeeper.
To remove quarantine information from a single object, perform the following steps:
You may sometimes receive files of unknown origin or with unknown document types. In other cases, files may have invalid type markers or file name extensions, for example a file displayed by the Finder to be a PNG image although it actually contains a JPEG image. To find out what is really contained in a file, you can have macOS look into the file letting it analyze what its contents may be. To do this, perform the following steps:
The analysis is done by the underlying operating system, not by TinkerTool System. For this reason the results may slightly vary in different operating system versions. The report is always displayed in English, no matter what preferred language you have set in your personal preferences.
You can only select one file at a time. It is not possible to analyze applications or other bundles. They will be simply identified as being a directory, the technical term for a folder. This analysis is correct, because bundles are actually folders which may contain a large number of different files although the Finder represents them by single file icons. To select one of the files inside a bundle, select it in the Finder and use the Finder’s feature Show package contents to open it as a folder. Then drag one of the contained files into the field of TinkerTool System.
In some cases, it might also be helpful to know which metadata the Spotlight search engine of macOS has collected about a particular object. To additionally display the Spotlight data, click the button Also show Spotlight metadata below the Results field. A table will appear which contains the complete list of Spotlight attributes for the selected object.
Badly written applications and installers which don’t handle permissions properly may leave files or folders on your system that cannot be moved into the Trash very easily. In other cases, applications may create a large number of files with write protection which also cannot be removed quickly. If you want to enforce removal of a large number of protected files, or if you want to remove a file from a folder with inappropriate permission settings, you can do so with the Force Delete feature:
The same problem outlined in the last section can appear when folders already have been moved into the Trash: Protection attributes may prevent that the Trash can be emptied successfully by the Finder. TinkerTool System can enforce deletion in this case, and offers the additional option that you can control which disk volumes will be affected by the Empty Trash operation. To use this feature, perform the following steps:
The objects you have put to the Trash yourself may not have been transferred to the general Trash of the volume, but to a separate Trash that you own. TinkerTool System will differentiate between these Trashes and will show your own Trash in the first line of the table in this particular case.
Modern operating systems and file systems have no limit how deep you can nest folders. However, there is a technical limit in the paths that are used to refer to these folders or the files they contain. In compliance with the POSIX industry standard, an operating system does not need to support file access paths with unlimited lengths when addressing a file system object in an application, command, or any function that works with file names.
In practice, this means that access to a file in a hierarchy of very deeply nested folders with long names may just fail, when the operating system does not accept that file’s absolute path because it is too long. Objects in such folders may become invisible on the graphical user interface, e.g. in the Finder, or in Open/Save panels, because the system is no longer capable of processing their oversized paths.
Note that paths depend on context and present situation. If a file is on your system volume named “Macintosh HD,” it may have an absolute access path like
If this disk is now mounted as external drive by a different Mac, the very same file may now be addressed by
/Volumes/Macintosh HD/Users/MyName/Documents/Some/Nested/Folder/Example/Document.txt ,
so the length of the path has increased by the part needed for “/Volumes/Macintosh HD” that the other Mac uses to refer to this external disk volume. Paths for identical objects can vary depending on how you combine multiple disks to build the entire file system hierarchy of the running computer. In enterprise networks, objects on file servers can become visible in arbitrary folders the network administrator has chosen for the client computers to use. In this case the paths are also just appended at run time. They are not stored anywhere.
Such deep folder hierarchies with overly long access names can be created by using relative paths instead of absolute paths. We won’t go into further details here, but the operating system alternatively supports the concept of a current working folder. You can tell the system to “go” into the folder at
then to navigate to the subfolder Some, then to navigate to its subfolder Nested, and so on, only using relative “navigation” instructions with short paths, instead of packing the entire specification of the file’s location into one single path specifier.
When referring to path lengths, not the plain number of characters, but the amount of memory used to store the characters when handling the path plays the crucial role. All modern operating systems use the Unicode UTF–8 encoding when processing file paths. With this encoding system, Latin characters, including characters with accents for many European languages usually need one byte per character. Characters of many Asian languages are stored as two bytes. Very specialized characters, such as Emojis, need four or even more bytes.
TinkerTool System can determine the maximum number of bytes the currently running version of macOS guarantees to be supported when referring to files via paths. It can also check whether all files in a folder hierarchy of a specified top folder can currently be addressed by absolute paths without exceeding this given limit.
Perform the following steps to check a folder hierarchy for overly long access paths:
The scan will begin. It can be canceled any time by clicking the Stop button in the status sheet. After all tests have been completed, the results will be shown in a different panel. If all objects are expected to be accessible, a green check mark symbol is shown. If one or more problems have been detected, the result panel will show
When using a reveal button, the Finder may not open the indicated file system item, because it is affected by the path problem itself, so it cannot correctly process the location of that item. Instead, TinkerTool System will instruct the Finder to open the “deepest” folder in the hierarchy that can still be safely displayed.
Although the shown folder can still be handled by the Finder, some or all of the folder’s contents may be invisible in the related Finder window, because the Finder is no longer capable of processing the items’ names at that deep level of the hierarchy. If you delete the supposedly empty folder, you may lose data!
You should rename the folder at this or a higher level, giving it a shorter name to resolve the problem. You could also move the affected folder to a higher position in the hierarchy instead. It would not be appropriate to do this automatically, so TinkerTool System won’t assist you further in this matter. The reorganization of folders should be done by the owner of the files who created the nested hierarchy.
Many of the additions to files already mentioned in this chapter, like HFS attributes or quarantine markers, constitute records of additional information, attached to a file or folder. Several other elements can be attached in such a manner as well, like color labels of the Finder, tags, Spotlight comments, backup markers of Time Machine and many other things. All modern versions of macOS collect such additional records as so-called Extended Attributes. Each Extended Attribute has a certain name, defined freely by the application which created and uses this attribute. Connected with each name is a certain sequence of bytes, representing the value or contents of the attribute. What exactly is stored as contents is at the discretion of the respective program. The number of Extended Attributes which can be attached to a file system object is theoretically unlimited.
Older versions of macOS or the classic Mac OS have used a similar concept known as named forks of a file. In particular, the so-called resource fork played the most important role. The advantage of using Extended Attributes or forks is that additional information can be stored together with the actual contents of a file (usually called data fork), using a single icon and single name for administration and transport. A disadvantage is that not all file systems (e.g. the FAT format of MS-DOS) are capable of storing such attributes. If a file, which has many attributes attached, is copied onto a disk not prepared for such operations, the additional streams of data can simply be lost. It also becomes more difficult to specify the true amount of storage space needed for a file, compared to the simple case.
Modern versions of macOS handle a resource fork internally as Extended Attribute with the name com.apple.ResourceFork.
There can be many different reasons to remove Extended Attributes from files. Here two typical examples:
You can specify a single file or a whole folder of files in TinkerTool System to let the program display all Extended Attributes associated with the objects. Afterwards, you can choose to remove one or all attributes with a certain name from the set of file system objects. Please note that read permission is needed for the affected folder and Extended Attributes. For the delete operation, write permission is needed, respectively.
Perform the following steps to display Extended Attributes, or to delete them, respectively:
Before any attribute is actually going to be deleted, TinkerTool System uses a dialog sheet where all found attributes and the file system objects they belong to will be listed:
The removal operation will start after clicking the button Delete in the sheet. No object will be touched if you click the Cancel button instead.
You should only use this feature if you know exactly what you are doing, in particular, which attributes are needed for what purpose. Specific documents may no longer open after their attributes have been removed.