Publishers of technology books, eBooks, and videos for creative people

Home > Articles > Apple > Operating Systems

  • Print
  • + Share This
This chapter is from the book

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.

SEE

Chapter 3 for more information on Console.

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.

SEE

"Problems opening files," earlier in this chapter, for related advice.

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.17Figure 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.

SEE

"Permissions/privileges problems with opening files," earlier in this chapter.

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.

SEE

Chapter 3 for more information on root access.

Figure 6.17Figure 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.

SEE

"Privileges," in Chapter 3, for many more details.

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.

NOTE

When creating a new file (such as via an application's Save command) or a new folder (such as via the Finder's Command-Shift-N command), you are assigned as the owner of the item. The group assignment for the item is typically the same as that of the folder containing the item. Thus, items created in the Applications folder would belong to the admin group.

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).

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

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

  6. Save your changes.

NOTE

If you are the owner of the file, you will be able to change read/write settings from the Finder's Show Info window for the file. If you are not the owner, the Privileges options will be dimmed. Even if you are the owner, the Show Info window will not let you change the owner or group name. That is why you need to use XRay.

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.

SEE

"Sticky bit and the root volume," later in this chapter, for a special case of changing settings to enable moving a file.

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


Figure 6.19Figure 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.

SEE

"Take Note: Default Settings of Applications," earlier in this chapter.

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.20Figure 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.21Figure 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.22Figure 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.

NOTE

If you log in as a guest, you will be able to access only the Public folder in Users directories. If you log in as an administrator instead, you will be able to access the entire contents of the drive.

TAKE NOTE

The Shared Folder

In addition to all the personal Home directory folders in the Users folder is a folder called Shared. The privileges of this folder are set so that Everyone has Read & Write access. Thus, this folder is like a community folder; any local user can view, modify, copy, or move anything there. This setup is not very secure, but it can be convenient for low-security items.

As it turns out, some applications also install items in this folder. Applications use it to store accessory files that need to be accessed by multiple users but that are not stored with the application itself. Font Reserve uses this folder for its Font Reserve database, for example, and America Online Instant Messenger (AIM) uses it for its icon and sound files. This situation can present a problem should you want to move the application. For starters, to copy the application to another volume, you would also need to remember to copy the files in the Shared folder. In some cases, however, simply moving the application from one location to another on the same volume can break the application's link to the files in the Shared folder, leading to problems with using the application. That's why it often makes more sense to use the application's installer to place the application in another folder rather than copy it.

NOTE

The contents of the Shared folder are not available to nonadministrative users when logged in remotely (a topic I cover more in Chapter 8).

TECHNICALLY SPEAKING

Move Your Home Directory to a Separate Partition

You can copy your Home directory to a separate partition via the Finder simply enough. This method can serve as a useful backup for your personal files, should you ever need to erase your Mac OS X volume and reinstall the OS from scratch. You cannot simply drag the backup copy of your Home directory to the new Users folder and expect it work, however. Instead, you will need to create a new Home directory and drag the individual files and folders from the backup copy to the folder locations of the new one.

If that process sounds like more hassle than you would like, there is an alternative: You can move your Home directory to a separate partition, where you can access it when running Mac OS X (instead of accessing it from the Users directory). In this case, if you need to reformat your Mac OS X partition, you will still have your Users directory preserved and can reconnect to it. Borrowing from the Mac FAQs & Tips site (www.bombich.com/mactips/homedir.html), here is what you need to do (for clarity, I have added an underscore wherever a space occurs; when you enter the commands, enter a space in lieu of the underscore):

  1. Launch Terminal, and type <sudo_ditto_–rsrc_/Users_/Volumes/OtherPartition/Users>.

  2. OtherPartition is the name of the partition where the new Home directory is to go.

  3. Type <sudo_niutil_-createprop_/_/users/username_home_\_/Volumes/OtherPartition/Users/username>.

  4. username is your user name.

  5. Check that the newly created directory is working by logging out and logging back in. Repeat the previous step for any additional Home directories you want to save.

  6. If all seems well, type <sudo_rm_-dr_/Users>.

  7. This command removes the old directory.

  8. Type <sudo_ln_-s_/Volumes/OtherPartition/Users_/Users>.

If you erase and reinstall your Mac OS X volume, you presumably can reconnect to the backup directory via step 2. Personally, I have never bothered to do any of this, so I cannot vouch for its success, although others have done so. Use this method at your own risk.

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.23Figure 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.

TECHNICALLY SPEAKING

Conceptualizing Directories in Unix

Conceptually, the sticky-bit discussion may make more sense if you realize that in Unix, a directory is not really a folder in the way that a folder appears in the Finder—that is, it is not a container but simply another file that lists the contents of what is considered to be in that directory. Thus, the permissions settings for a directory determine only the extent to which you can modify the listing. But this setting is separate from your ability to modify the files themselves. The latter capability is determined by the permissions set for each file. In other words, a lack of read access for a directory means that you cannot read the directory listing. It does not mean you cannot read the files within the directory. Nor does it mean that you cannot change the contents of the listing.

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.24Figure 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.

TAKE NOTE

Package Contents Won't Open

After making a copy of an .app application, if you try to access the contents of the package (by choosing the Show Package Contents command from the contextual menu), you may meet with resistance. The Show Package Contents command opens the package normally enough, but the Contents folder inside is dimmed and cannot be opened.

Solution? Just log out and log back in. All should be well.

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.

TECHNICALLY SPEAKING

SetUID and SetGID

Occasionally, Unix users need access to a function that they would be prohibited from accessing otherwise. To change your password, for example, you need access to the function that changes passwords. But this access is restricted to the root user; otherwise, any user might be able to change anyone's password. Unix works around this dilemma by providing an option that allows a user to access the password function just to change his or her own password.This task is accomplished by having the SetUID bit enabled for the function.This bit has a similar effect for any other command for which it is set. With SetUID enabled for a command, the command is run as though the person running it has the permissions of the owner of the file (root, in the password example) for the action attempted. As long as you have permissions to access the other files needed to complete your request, the command should work. So any user can change his or her own password.

The SetGID bit works similarly, except that the normal group permissions are shifted temporarily to those of the group that owns the command in question. This bit has a somewhat different effect when applied to a directory rather than a file. In any case, you will have no need for this command, and I mention it only for the sake of completeness.

As covered in the main text, setting the SetUID bit for a file also has some effects in Mac OS X that are a bit different from those described here for standard Unix.

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.

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

  4. Press Return.

  5. 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.25Figure 6.25 The SetUID option enabled in XRay.


TECHNICALLY SPEAKING

Copying from Terminal

If you are having trouble getting a file to copy from the Finder, you may be able to succeed by copying the file via Terminal. In one case, an application (called GetInfo.app) that I had backed up to a CD would not copy back to my hard drive. I kept getting an "unexpected error (Error code –50)" message.

This error usually is the result of a bug in the OS. In this case, I found that some files in the Frameworks folder inside the application package had an alias icon, even though they were not alias files. Somehow, these files were triggering the error.

cp. To solve this problem, I launched Terminal, navigated to the location of the file on the disc (by using the <cd> command) and typed:

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

This command instructed the OS to copy the entire application to my Home directory. Use the -r option if what you want to copy is a directory rather than a single file, because the application—being a package—is really a directory.

This method successfully copied the file for me. End of story.

This command works as long as there are no resource forks in the files being copied. The <cp> command does not copy resource-fork code. If you are unsure whether a file contains a resource fork, don't worry. If <cp> fails to work, you can delete the resulting partial copy and try again with another alternative. Or you can skip <cp> and go directly to the potential alternatives.

ditto. One alternative is the <ditto> command (a built-in Unix command created by Apple). Its format is the same as that of <cp> except that you will likely need to log in as a root user to use it. To do so, type:

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

No -r option is needed , as <ditto> is designed to copy directories. In fact, you cannot use it to copy just a file. The <ditto> command overwrites existing files, symbolic links, and devices in the destination when they are copied from a source. The resulting files, links, and devices will have the same mode, owner, and group as the source items from which they are copied. This command was not created specifically to deal with the problem of resource forks, but users report that it does copy them successfully. Some users have even employed this command as a way of backing up their drives.

CpMac. Finally, if you have installed the Developer Tools software (available on a CD included with a purchase of Mac OS X or otherwise available for download from Apple's developers' Web site), you can use the <CpMac> command. This command is a special version of <cp> that does copy resource forks. You can execute the <CpMac> command by typing its directory entry in Terminal, followed by the paths of the file you want to copy and its destination location. For example, for GetInfo.app, it might look like this:

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

Note: There is no manual (man) entry for CpMac. But if you type the command with no items to be copied, you will get a brief explanation of its use.

SEE

  • "Take Note: Type and Creator vs. File Extensions," in Chapter 3, for more information on resource forks.

  • Chapter 10 for more information on Terminal and copying files.

Figure 6.26Figure 6.26 Error message that may appear when you're attempting to copy a file.


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.

SEE

"Take Note: Backing Up Mac OS X: Utilities to Use" and "Take Note: Backing Up Mac OS X: Hardware and Strategies," in Chapter 5.

  • + Share This
  • 🔖 Save To Your Account