Problems with OS X Files: Open, Copy, Delete, and Beyond

This chapter is from the book

Mac 0S X Disaster Relief: Troubleshooting Techniques to Help Fix It Yourself

Learn More Buy

This chapter is from the book

This chapter is from the book 

Mac 0S X Disaster Relief: Troubleshooting Techniques to Help Fix It Yourself

Learn More Buy

Copying and Moving: Problems Copying and Moving Files

If you attempt to copy, move, or duplicate a file and are unsuccessful, consider the following causes and solutions.

Insufficient space

If you try to copy a large file to a volume that has less free space than the size of the file, you will be unable to do so. Not a surprise.

The solution is to delete unneeded files from the destination volume, so as to free more space. Or you can attempt to copy the file elsewhere, on a volume that has more free space.

Occasionally, a volume may seem to have less space than you expected, based on the files you installed. This situation usually happens because some OS-related file—sometimes, an invisible file—is taking up more than the usual amount of space. Examples include the Console log files. If these files are not updated periodically, or if a recurring error is filling them rapidly, they can become very large. Explorer cache files can also become quite large. The solution is to locate these files and delete them. You can use Sherlock to search for files by size. This technique will help you spot unexpectedly large files.

File is corrupted

Sometimes, you will be unable to copy a file because the file is corrupted, and the Finder is unable to read the file's contents. In general, your best bet is to delete the file and start over with a fresh download, backup copy, or new document. If you absolutely need to try to recover the information in the file, you can try opening it in its creating application (such as Word for a Word document), copying what you can to a new document and saving the new document. In other cases, an text editor such as BBEdit will allow you to at least view the text within a document, allowing you to save it even if nothing else can be saved. Otherwise, attempting disk repairs (such as with Disk Utility) may recover the item. Barring that, give up on the file and delete it.

File does not appear after being moved

Occasionally, when you're copying a file, especially to the Desktop, the file may not appear on the Desktop when the copy is complete. This situation most often happens when you're decompressing a file from an archive or downloading a file from the Internet, or when the file is being moved or created from an application other than the Finder itself.

In almost all cases, the file is really there; the Finder has not been updated to reveal it. You need to give the Finder a bit of a push. For files that do not appear after being downloaded from Explorer, open Explorer's Download Manager; double-click the name of the missing file; and in the window that appears, click the Reveal in Finder button. The item should become visible. As a last resort, choose Force Quit and reload the Finder. This procedure should get the file to appear.

Figure 6.17 The Reveal in Finder button in Explorer's Download Manager.

One other possibility, for files on the Desktop, is that the file was copied to a Desktop other than your Mac OS X Desktop. The file may have been copied to a Mac OS 9 Desktop that resides on the same volume as Mac OS X, for example. In this case, double-click the Desktop (Mac OS 9) icon that should be on your Mac OS X Desktop if Mac OS 9 and Mac OS X are on the same volume. When Mac OS 9 is on a separate volume, simply open the Desktop Folder on the Mac OS 9 volume. You will find the missing file there.

Permissions/privileges problems with copying/moving files

If you try to copy or move a file, and you get an error message that says, "The operation cannot be completed because you do not have sufficient privileges for {item or folder name}," you have a privileges-related problem.

For a copy, the problem is always at the destination end—where the copy is to go.

For a move, the problem could be at either end. When you move a file, you may not have sufficient privileges for it to be removed from its original location, or you may not have sufficient privileges for it to be copied to its new location.

Why do these permissions errors occur, and what can you do about them?

Files that should not be moved. In general, you should not touch files in the /System folder. Unless you are confident that you know what you are doing or are specifically instructed to modify this folder by someone else who knows what he or she is doing, avoid removing or modifying any files in this folder. Generally, Mac OS X will prevent you from making changes anyway. But just in case...you've been warned.

Similarly, you cannot add a file to the System folder for the same basic reason. If you try, you will likely get an error message that says, "The item {name of file you are trying to move} could not be moved because {name of System-folder directory} cannot be modified." Generally you want to follow this advice.

If you absolutely need to move a file to or from these forbidden locations, you will need root access to do so. You may also need to change permission settings, as described in the following paragraphs.

Figure 6.17 The Reveal in Finder button in Explorer's Download Manager.

There are similar limits on access to other Mac OS X folders. Administrators can add files to or remove files from the Applications folder, for example, but other users cannot. This limit can cause some odd situations. A file can be copied from the Applications folder by a nonadministrative user, but that user cannot copy the file back to the folder (due to insufficient privileges). The best solution is to have someone with administrative access handle these tasks.

Files with incorrect permissions/privileges settings. Almost every file in Mac OS X has an owner and a group assigned to it. In addition, the owner and group (together with a third category that includes everyone who is not the owner or in the group) each has certain permissions to read or manipulate the file. You can see the basic permissions settings (called privileges in Mac OS X) by opening the Show Info window for a file and choosing Privileges from the pop-up menu.

If you are neither the owner of a file nor a member of its group, and especially if read or write access is not given to Everyone, you may be unable to copy, move, or otherwise modify the file due to insufficient privileges. You cannot move a file out of a folder, for example, if you are not the owner of the folder or a member of its group. (An exception can be if you are the owner of the file.) This is the reason that nonadministrator users cannot move files into or out of the Applications folder, which is owned by system with a group assignment of admin. Only the system (which essentially means Mac OS X itself or the root user) or a member of the admin group (which includes all administrators) can modify the contents of this folder.

The /System folder lists its owner as system and its group as wheel. In this special case, you cannot move files into or out of this folder, even if you are a member of the wheel group (which you are, as an administrator), without first getting root access. This is because the wheel group only has Read access for the /System folder.

When you're copying or moving a file, the file's ownership may get modified. In particular, here's what may happen and why:

Moving and permissions. If you move a file from one location to another, the file generally retains its permissions settings. Thus, if you move an application from the Applications folder to your Home directory, it will retain system and admin as its owner and group.

Conversely, if you move a file from your Home directory to the Applications folder, it will retain the permissions settings it had in your Home directory. Depending on what those settings were, nonadministrative users may not be able to launch the file due to insufficient access. In such a case, the solution is to modify the file so that it acquires the system and admin attributes of most other files in the Applications folder.

Copying and permissions. If you copy a file from one location to another, the copy generally acquires the attributes of its enclosing folder. Thus, if you copy a file from Applications to your Home directory, it will acquire your user name as the owner and staff as the group.

Conversely, if you copy a file from your home directory to the Applications folder, its permissions change to that of system and admin. Thus, you are no longer the owner of the file you just copied. In this slightly odd situation, you may be able to modify the privileges settings (via Mac OS X's Show Info window) of the original file but not those of the copy.

Occasionally, usually due to some bug in an installer utility, the ownership of a file may get modified so that even as an administrator, you do not have immediate access to move or replace the file. Usually, the utility assigned system/wheel as the owner/group of the file.

In one example, the Applications folder may be locked or have incorrect permissions after you install a Mac OS X update. This situation may also happen after you use an installer utility for third-party software. Later, when you drag a file or folder to the Applications folder, the following error message will appear: "The item 'filename' could not be moved because 'Applications' cannot be modified." To fix this problem, you can use the techniques described later in this section.

As an administrator, you can change whatever you want; you just need the right tools and a bit of know-how. In particular, you can accomplish your goal by using one or more of the following techniques:

• Rebooting in Mac OS 9 (where Mac OS X privileges settings are not enforced) and then copying or moving the file as desired.

• Making changes in Terminal (as covered briefly in Chapter 10).

• Logging in as a root user (as covered in Chapter 3).

• Using a utility such as XRay to change the owner, group, or read/write settings—or some combination of the three.

Of all the choices, I prefer staying in Mac OS X's Aqua interface and being logged in as usual. Thus, I prefer using a utility such as XRay. In particular, here is how to use XRay to change permissions:

Change permissions of an individual item. To change the settings for one file or folder, follow these steps:

1. Launch XRay, and drag the icon of the file you want to modify to its window.

2. Choose Permissions from the Show pop-up menu.

3. Change the owner and group name to whatever you want (such as system and admin for files in the Applications folder or select your own name as the owner).

Pop-up Owner and Group menus make it easy to see what your choices are and to make your selection.

4. Make sure that owner and group have Read, Write, and Search/Execute status enabled.

5. Save your changes.

Change the permissions of all items in a folder. Suppose that you want to reset all applications in the Applications folder so that they have the same settings as they did when you installed Mac OS X. It might seem that you could do this by opening the Show Info window for the Applications folder, going to the Privileges tab, and clicking the Apply button. This method would convert all the contents of the Applications folder to match the attributes of the Applications folder itself. Unfortunately, you cannot do this directly, because you need to be the owner of the folder, and system is listed as the owner.

XRay allows you to work around this problem. Follow these steps:

1. Launch XRay, and drag the icon of the folder you want to modify to its window.

2. Choose Permissions from the Show pop-up menu.

3. Click the padlock icon to unlock special fields, and enter your administrator's password.

4. Click the disclosure triangle next to Show Options.

5. Click the Change Enclosed button.

6. Make the Owner, Group, and World options match the settings for the folder itself.

7. Click the Save & Change Enclosed button. You are done.

Follow the same general principles for making these permissions changes for any file or folder.

Figure 6.18 XRay's Permissions tab (with the pop-up menu for changing owners visible).

Figure 6.19 (Left) The Show Info window's Privileges tab and (right) XRay's Permissions tab (with its Changed Enclosed window open) for a folder.

Folders with incorrect privileges settings. The same logic that applies to files applies to folders. In one case, however, Apple has noted that the Mac OS X Applications folder may wind up with incorrect permissions after you update the OS. The result will be that you cannot modify the contents of the folder. As a quick fix for this problem, Apple released a FixApplicationsFolderPermissions application.

Ignore privileges on this volume. On all mounted volumes except the Mac OS X startup volume, if you go to the Privileges tab of the Show Info window of the volume, you will see an option called Ignore privileges on this volume. If you enable this option, it should do what its name implies; you will be able to access files on this volume, even if you otherwise would not have the privileges to do so.

Figure 6.20 The Ignore Privileges option enabled for a volume.

This option is intended primarily to deal with mounting external volumes that you get from other users. The permissions settings for such a volume may be set so that unless you are the person who loaned you the volume, you cannot access the files. More than likely, if the person lent you the volume, this was not his or her intention. Clicking Ignore Volumes works around this dilemma.

A word of advice: I have found that enabling this option when it is not needed can precipitate problems. Without going into details here, I'll just say leave this option off unless you need to enable it to access a file on a volume. Turn it off when you no longer need to use it.

Accessing other users' folders

Assuming that you are the person who installed Mac OS X on your Mac, you are an administrative user. Further assume that you set up a few additional nonadministrative users via the Users System Preferences window (covered in Chapters 3 and 8)—say, for other family members or colleagues. Each user gets his own Home directory, as stored in the Users folder. Finally, assume that as the administrator, you would like to be able to check on the contents of the Home directories of these other users. Can you do this? Of course. But you will have some obstacles to overcome.

No entry. For starters, if you open the Home directory folder for another user, you will find that your access to most of the folders within it is blocked (the Desktop, Documents, Library, and most of the other folders created by Mac OS X when the directory was set up) because the folders have a privileges setting of None for Group and Everyone, as can be seen in the Privileges tab of the Show Info window for the folders. Thus, only the owner of the directory can access these folders, and the folders have a red "no entry" icon on them. Some files and folders may have different privileges settings, providing you with some access, but they will likely be the exceptions.

Figure 6.21 Inside another user's Home directory. Note the "no-entry" icons on most of the folders.

Public and Sites folders. The only sure exceptions will be the Sites folder (where you would store a Web site enabled by Web sharing, which needs to be available publicly) and the Public folder (which is where you store files that you want anyone to be able to access, such as other local users on your Mac or people who accesses your Mac with guest access via file sharing). These two folders have the Group and Everyone privileges set to Read Only (as opposed to None, so you can open and view the contents of the folder. What you can do with the viewable contents will depend on the privileges setting of each file and folder:

• If a document has Read & Write privileges enabled for Everyone, you will be able to open and modify the file.

• If privileges are set to None, you won't be able to open the file, even though you can see its icon in the Finder.

• If privileges are set to Read Only, you will be able to read but not modify the file. If you open the file, make a change, and try to save the file, you will get an error message. You will be able to copy the file to your drive, however, and modify the copy there.

Drop Box. Within each user's Public folder is an additional folder named Drop Box. This folder is designed so that you can add to its contents but not see them. This folder is almost the opposite of the rest of the Public folder, which is designed to allow you to see the contents but not necessarily modify them.

The Drop Box allows you to leave files for the user who owns the Drop Box without being able to see or access what other people may have left. To accomplish this goal, the Show Info privileges for a Drop Box have been set to Write Only for Group and Everyone.

Figure 6.22 The Privileges settings of your (left) Drop Box and (right) Public folders, as viewed in their Show Info windows.

Administrative access. In the preceding examples, being an administrator has not given you access beyond what any other user would have. But as an administrator, you have additional options. To peek inside restricted folders and possibly modify the files within, use these methods:

• Use Terminal. Type <sudo ls>, followed by a space. Then drag the folder you want to inspect to the command line. You will see the absolute path name for the folder. Press Return. You may be asked to enter your password. Do so. The contents of the folder will appear. You also can use the Terminal's open command to open a file within the folder (although you may not be able to modify the file).

• Log in as root. You will have complete access to all no-entry folders. You can not only view the contents but also modify them.

• Connect to Server. If you have two Macs connected via a local network (as discussed in Chapter 8), use the Connect to Server option to mount the Mac you want to access from the other Mac. When you're asked to log in, use the name and password of an admin user (presumably, you). You will have access to the contents of all users, even though you do not when you are working directly from the Mac in question.

Sticky bits and the Drop Box

In this section, I take a closer look at the privileges/permissions settings of a Drop Box. Along the way, I will also explain some generally relevant tidbits about something called the sticky bit.

The permissions of the Drop Box. As I have already noted, the Show Info window's privileges for a Drop Box folder are set to Write Only for Group and Everyone. You might think that this setting means what it says: No one except the owner (or someone with root access) can read or modify the files in that folder. But you would be wrong.

Leaving the Show Info window, take a closer look at the actual Unix-style permissions settings of the Drop Box, using either Terminal or a utility such as XRay. When you do this, you discover that the permissions for Everyone are <-wx>, which means that Everyone has write (w) and execute (x) permission for the folder. For applications, execute permission means that you can run/execute the file. For folders, however, all that the execute permission does is allow the other permissions (r and w) to have any effect at all. In fact, when used with folders/directories, the x bit is often referred to as the search bit rather than the execute bit.

Figure 6.23 The permissions of the Drop Box, shown in XRay.

Thus, with <-wx> permission for Everyone for a folder, a user can add files to the folder and also remove files from the folder. In fact, omitting read access means only that you are unable to view/read the contents of the directory. That is why when you drag a file to the Drop Box, you get a message that says, "You do not have permission to see the results of this operation." Similarly, if you double-click the Drop Box, you will get the "You do not have sufficient privileges" error.

This situation does not mean that you cannot read individual files within the directory, however. You can read the files—if their individual permissions settings allow. Even though the folder does not have read permission set for the Drop Box, you potentially can still read and modify a file within the folder (including deleting the file). Thus, files in such a folder are less secure than they may seem.

Typically, this situation is not much of a concern. As you can't view what is in the Drop Box folder, it would be hard to open anything inside it. But if you knew the name of a file in someone else's Drop Box, you could read it and (depending on the file's permission settings) modify it. Even if you did not know the name of the file, you might be able to use a utility that lists what is in these off-limits folders and thereby gain access to it. You could take a guess

at part of the file's name, for example, and enter the partial name in Sherlock. If your guess matches anything contained in the Drop Box, the file will appear in Sherlock's results. If you have read or write permission for the file, you will be able to double-click the file in Sherlock's window and open it—despite its Drop Box location.

The sticky bit. So is there a way to improve on the security of the Drop Box? Yes. To restrict access further to the contents of this (or any other) folder, you can set the sticky bit for the folder. The sticky bit is a special Unix attribute setting beyond the standard read, write, and search/execute ones I have described so far.

If the sticky bit is set for a folder, anyone can add files to the folder, but only the owner of the folder can remove anything from it. Actually, the owner of a file should also be able to remove that particular file. This situation does not prevent someone from opening and reading a file in a Drop Box (assuming that the person knew the name of the file and had read access to it), but it does prevent that person from renaming or removing the file. In some cases, the setting will also prevent modifications to the file. However, to guarantee that any non-owner read access or modification for a file is prohibited, you need to modify the permissions of the file itself (setting Group and Everyone access to None), not the folder that contains the file.

Bottom line: The Mac OS X Show Info window's Write Only privileges setting suggests a different meaning to non-Unix savvy users than it actually means. Despite the name, you have more than Write access to files in the folder. This setting is also different from what it means in Mac OS 9, in which all access to files in a Drop Box are blocked with Write Only access.

Set the sticky bit. Having decided that you want the extra security of setting the sticky bit for your Drop Box, how do you set it? Two ways: Use Terminal or a utility such as XRay. I'll explain both alternatives briefly.

To use Terminal to add the sticky bit to the Drop Box folder, follow these steps:

1. Launch Terminal, and type <cd Public>.

2. Type <ls -l>.

   The permissions for the Drop Box should read drwx-wx-wx, which means that you have a directory (d), that the owner has rwx (read, write, execute) permission, and that Group and Everyone have just -wx permission.

3. Type <chmod 1733 "Drop Box">.

   The permissions should now read drwx-wx-wt. The last t indicates that the sticky bit is set.

   or

   Type <chmod go=wxt>.

   This command has the same net effect as <chmod 1733 "Drop Box">. Briefly, it sets the access for Group (g) and Other (o) to be equal to (=) write, execute, and sticky bit but provides no read access (-wxt).

   SEE

   Chapter 10 for more information on using the chmod command.

To use XRay to add the sticky bit to the Drop Box folder, follow these steps:

1. Open the folder you want to modify in XRay (Drop Box, in this example).

2. Go to the Permissions tab via the Show pop-up menu.

3. Click the disclosure triangle next to Show Options.

4. In the Special Mode Bits section, click the Sticky checkbox.

5. Save the changes.

Note: Examine the boxes just below the Show pop-up menu. You will see the same sort of attribute listing for the folder that you can see in Terminal when you list files by using <ls –l>. When you enable the Sticky checkbox, the last letter in the listing will change from x to t. For Drop Box, it will change from <drwx-wx-wx> to <drwx-wx-wt>. Again, this change indicates that the sticky bit has been set.

The adjacent text box in XRay will change from <chmod 0733> to <chmod 1733>. This setting refers to the chmod (change mode) commands needed to turn the sticky bit on and off. A 0 as the first digit means that the sticky bit is off; a 1 means that it is on.

Figure 6.24 The Drop Box folder with sticky bit enabled, shown in XRay.

Sticky bit and the root volume. The sticky bit is enabled automatically for the root-level directory when you install Mac OS X. The root level is the level that has the name of the volume as its window name in the Finder (where you see System, Library, Users, Applications, and other folders). Thus, anything that is copied to that window cannot later be moved via a simple Finder drag by anyone other than the owner of the item or by someone who has root access. Thus, if another user on your Mac adds a file to that window when he or she is logged in, you will not be able to drag the item to the Trash, for example, even though you are an administrator.

The simplest way to get rid of the file is to use XRay to make yourself the owner of the file or folder (as described in "Permissions/privileges problems with copying/moving files" earlier in this chapter). Then you can move it or trash it as desired.

More generally, for almost any problem with moving a file from a folder with the sticky bit enabled, you can turn off the sticky bit temporarily, complete your move, and then turn the sticky bit back on. To do this via XRay for the root directory, drag the Mac OS X startup-volume icon to XRay, and uncheck the Sticky checkbox. Or use the following command in Terminal: <sudo chmod 775 />. After returning to the Finder and completing whatever you wanted to do, recheck the Sticky checkbox in XRay or type <sudo chmod 1775 /> in Terminal.

SetUID and "Items could not be copied" error

Occasionally, when you try to copy an application, you may get an error message that says: "One or more of items can't be copied. Do you want to skip them and copy the remaining items?" If you click Continue, you will get what appears to be a copy of the application, but if you try to launch it, it will not work. Typically, you will not get an error message. Instead, the application will simply start to launch and then quit.

This happened to me, for example, when I tried to copy the Open Firmware Password utility (discussed in Chapter 5) from the Mac OS X Install CD to my hard drive. It also happened on one occasion when I was making a copy of the Mail application.

The following paragraphs explain what causes the problem and how to work around it.

Boot and copy from Mac OS 9. You can work around the problem by booting from Mac OS 9 and copying the utility from there. When you return to Mac OS X, the utility will run. Yet again, the problem is related to permissions settings and is enforced only in Mac OS X.

Get copy to work in Mac OS X. What is it about permissions settings in Mac OS X that causes this odd behavior? To find out, start by comparing the package contents of the original application and the failed copy to see what is different, if anything.

In the case of the Open Firmware Password utility, you will see that the essential Open Firmware Password file, located in Open Firmware Password/ Contents/MacOS, was present in the utility on the CD but not in the failed copy. Similarly, for Mail.app, the critical Mail file itself (in the Mail.app/ Contents/MacOS folder) is missing from the copy. As these files essentially contain the program code of the applications, it is no wonder that the copies did not work.

SetUID setting. Why didn't the files within the package copy successfully? The file has its SetUID bit enabled! You can determine whether this bit is enabled by using Terminal or XRay.

To use Terminal, mount the Mac OS X Install CD and type:

<ls -l /Volumes/Mac\ OS\ X\ Install\ CD/Applications/Utilities/OpenFirmware\ Password.app//Contents/MacOS/>

Or, more simply, type <ls –l>, followed by a space; drag the icon of the file (for example, Open Firmware Password) to the Terminal window, automatically add the preceding path; and press Return. The Open Firmware Password document will have its attributes listed as <-rwsrwxr-x>.

Note the s, instead of the more common x, at the end of the first trio of letters (rws instead of rwx). This setting means that setUID (set user ID) bit has been enabled for the owner.

To use XRay to confirm that the setUID bit has been enabled, follow these steps:

1. Drag the Open Password document from the MacOS folder within the utility's package to XRay.

2. Go to the Permissions tab.

You will see rws as the first trio of letters. In addition, if you click the disclosure triangle to Show Options, you will see that the SetUID check-box has been enabled.

Apparently, if a file has its SetUID bit enabled, it cannot be copied in the Finder. In Unix, the result of the copy attempt would be for the file to copy with the SetUID bit stripped off. In Mac OS X, the file apparently refuses to copy at all.

Thus, the solution to the problem with copying programs such as Open Firmware Password is simple enough: Disable the SetUID bit for the file. Then the file will copy successfully. The copy should also run successfully with SetUID still off. If you have any problems, you can always reenable the SetUID bit.

To disable (or reenable) the SetUID, the simplest method is to use XRay or some similar Mac OS X utility. To do so with XRay, follow these steps:

1. Select Show Package Contents from the contextual menu of the application that contains the setUID-enabled file.

2. Open the setUID-enabled file with XRay (see XRay instructions earlier in this chapter for more details, if needed).

3. Click the padlock icon, and enter your administrator's password when requested.

4. Select Permissions from the Show pop-up menu and click the Click to Show Options disclosing triangle.

5. Uncheck the SetUID checkbox.

6. Save the change.

You can reverse the change later, if necessary.

To use Terminal, follow these steps:

1. Type <sudo chmod u-s>.

2. Press the spacebar, and drag the Finder icon of the setUID-enabled file (in the package of the application) to the Terminal window.

This action will enter the full (absolute) path name for the file.

3. Press Return.

4. Give your administrator password when you are asked for it. The change should be made. If you navigate to the directory that contains the file and type <ls -l>, permissions for the file should read <-rwxrwxr-x>.

After using either method, if you attempt to copy the original package utility, it should copy successfully. If you are familiar with Unix and the Mac OS X Developer Tools software, you may be able to use commands such as <diito> or <CpMac> to copy a file in Terminal, even without disabling the file's SetUID bit. I recommend that most users stick with the more basic methods described in this section, however.

Whatever the rationale Apple had for enabling the SetUID bit on certain files, one thing becomes clear: It can be an effective form of copy protection. If you enable the SetUID bit on a volume for which the user does not have administrative access, there is virtually no way for the user to copy the file.

Figure 6.25 The SetUID option enabled in XRay.

<cp –r GetInfo.app ~/GetInfo.app> 

<sudo ditto GetInfo.app ~/GetInfo.app> 

</Developer/Tools/CpMac –r -mac GetInfo.app ~/GetInfo.app> 

Copying to back up

If you are wise, you will want to back up the contents of your drive periodically. Backing up is a protection against software or hardware damage that could mean the loss of the contents of your drive. Backing up a drive in Mac OS X—especially if you want to make a backup that can restore a volume, including making it bootable—presents some challenges that do not exist in Mac OS 9.