Explaining the Finder's view options and toolbar visibility

Mar 07, '03 08:47:00AM

Contributed by: noworryz

This hint explains why Finder windows behave as they do in OS X 10.2: why View Options and the visibility of the toolbar sometimes seem to spontaneously change and icons spontaneously move. Two previous hints ( 1, 2) offered incorrect advice for fixing the problems.

There are actually five different types of window state, all handled differently by the Finder:

  1. The state of open windows when you log out, which causes them to reopen when you log back in.
  2. The default "All windows" view options.
  3. The file icon locations and file comment text.
  4. The custom "This window only" view options and the position and size of the window.
  5. The visibility state of the window's toolbar.

The Finder saves the state of your open windows when you log out so that it can open them when you log back in. The state contains everything needed to make the windows appear exactly as they were at log out: toolbar visibility, scroll position, size, location and view style. At log in time, it overrides all other options controlling the window view. It is stored in your ~/Library/Preferences/com.apple.finder.plist file when, and only when, you log out. (View the file with Property List Editor; list name is WindowState.) Confusing behavior happens if you log in with open windows, close them, then relaunch the Finder (by doing a command-option-esc Force Quit). The windows pop open again because the Finder never saved the new state.

[robg adds: Read the rest of the article for a very thorough explanation of window settings, along with some advice for Apple on how to make window setting behavior a bit more Mac-like. And thanks to Glenn [aka noworryz] for writing this up in such a complete and easy to follow manner. I can't claim that I've tested each and every item mentioned in the following explanation, but it all seems to make sense ... as always, comments and corrections are welcomed!]

The Finder saves the default "All windows" view options, which it uses in a complicated way, described later. To change these options, make a Finder window active (non-transparent title bar), select Show View Options (or command-J), click on "All windows", and make a change to the options. The options are saved within a minute, also to your com.apple.finder.plist file (list name: StandardViewOptions).

The Finder saves file icon locations for use when the window containing the files is in icon view and the arrangement is not forced by "Keep arranged by" options. You change these locations by dragging around icons in icon view. The Finder also saves the file comment text created by typing in the "Get Info" window. Both types of file information are saved in an invisible file called .DS_Store located in the directory shown in the window; i.e., the one containing the files themselves. (Type ls -laF in the Terminal to see the file.) It is written when the volume containing the directory is ejected or you log out. (If you try to eject your startup volume, the file is written before the "disk is in use" alert pops up.) Confusing behavior happens if you add comments or move icons around, perhaps for hours, and then relaunch the Finder before an eject or log out. You will lose all your changes.

The .DS_Store file is in a binary format kept secret by Apple. As of March 2003, there are no tools to view and modify its content, other than the Finder.

The Finder saves a window's custom "This window only" view options and the position and size of the window, which it uses to draw the window whenever it is opened. The options include whether the window uses the custom or default view options, the list/icons/columns type choice, size of icons, label text size, label position, show info/preview flags, "keep arranged by" options, and the window background. To change these options, make the window active, select Show View Options (or command-J), click on "This window only", and make a change to the options. This information is kept in a .DS_Store file that is not located in the directory shown in the window. Instead, it is stored in the parent directory; i.e., the directory containing the directory shown. As before, you can change window views for hours, only to lose all your changes if you relaunch the Finder before you eject or log out.

The Finder saves the visibility state of a window's toolbar exactly as it saves the custom view options: in the .DS_Store file located in the parent directory of the one shown in the window. What is confusing is how you set this state because of the Finder's toolbar visibility hack. If a Finder window is active and you either double-click or type command-O to open a folder within it, a new window opens if the Finder's "Always open folders in a new window" preferences checkbox is ticked. This new window will always have the same toolbar visibility as the previously active window; the Finder ignores the saved visibilty state. However, if you drag and hold something over the folder, the window that pops up will reflect the saved state. Similarly, if you open the same folder via an alias on the desktop, via the "Go/Go to folder..." menu item, or via the "Go/Recent Folders" menu, the new window will reflect the saved state. None of these operations change the saved state; to do so you must click the window's toolbar visibility control or press command-B. If the visibility appears to be already the way you want it, you have to click or press command-B twice to actually change the state. As always, you lose all your changes if you relaunch the Finder before you eject or log out.

Missing in action

How does the Finder draw a window when the .DS_Store file is missing? For Unix File System (UFS) volumes, it uses the default view options. However, for the normal Hierarchical File System (HFS+) volumes, the answer depends on whether or not you have ever looked at the directory with the OS 9 Finder!

When you view a directory for the first time in OS 9, the Finder assigns window positions to all the files and folders within it and assigns a view type (icons or list) to the directory itself. This information is stored in the HFS file structure, along with a flag bit, called the Inited attribute, that indicates the information has been initialized. (You can see this information with the OS X /Developer/Tools/GetFileInfo command.)

When the OS X Finder needs to draw a directory for which there is no .DS_Store file in the parent directory, the Finder examines the Inited attribute of the directory being drawn. If the bit is clear, the Finder uses the default view. If the bit is set, the Finder assigns the directory a custom view, making it a list view type if it was a list view in OS 9. The custom view always has the text size set to 12 points, the icon size set to 32 x 32, labels on the right, no info/preview, and the background set to white.

The OS X Finder then looks within the directory to see if there is a .DS_Store file. If not, any files or folders within the directory that have their Inited attribute set are given the icon locations used by OS 9.

Whenever .DS_Store is missing, the directory toolbar is made visible (although the toolbar visibility hack may prevent you from seeing it). This applies whether the volume is UFS or HFS and whether the Inited attribute is set or not.

At the next log out or eject, the Finder tries to create the missing .DS_Store files.

Permission to go mad

Have we reached the end of the weirdness? Not even close, because OS X is a multi-user system and there is only one .DS_Store file per directory, shared among all the users. Even if you are the only user, you may not have permission to write the file in some directories.

If you make changes to a window's view but the permissions do not allow the Finder to write the appropriate .DS_Store file for the window, you will lose your changes, without warning, when you log out or eject the volume. Whether or not the Finder can write a .DS_Store file depends upon the permissions and ownership of both the file and the directory in which it is contained (type ls -laF in the Terminal; man ls for the manual). It also depends upon the groups to which you belong (type groups in the Terminal).

The Finder will write the .DS_Store file if you have write permission for the file's enclosing directory, either because you are the owner of the directory and the directory's permissions say the the owner may write or because you are in a group that matches the group of the directory and the directory's permissions say that the group may write or because the directory's permissions say that everyone may write. The Finder will delete the old .DS_Store file (if it existed) and create a new one, owned by you, to take its place.

The Finder will also write the .DS_Store file if you do not have write permission for the file's directory but you do have write permission for the file itself (and it exists). In this case, the ownership of the file remains the same but the Finder overwrites the contents.

You will seldom have problems with file and directory permissions in your Home directory tree unless you've moved directories from elsewhere or other users have been poking around. If so, you can type the following commands in the Terminal to set the permissions so that you, and only you, can write in your directories. You can also use the commands to fix the directories of another user (~someusername is a tilde immediately followed by a user's name):

sudo chown -RP someusername ~someusername
sudo chgrp -RP staff ~someusername
sudo chmod -RP u+rwX,g-w,o-w ~someusername

Problems are more likely in the Apple-supplied directories such as /Applications, /Library, or /Developer. However, it is dangerous to use commands that change the permissions of every directory, especially in the /System directory tree or any of the hidden directories (/Volumes, /bin, /etc, for example). If you do, the system may no longer boot from your startup disk, requiring you to boot from the OS X Install CD, select "Open Disk Utility..." from the Installer menu, click on "Repair Disk Permissions" in the First Aid tab, and wait a half-hour or so. You may also have to manually change the permissions of third-party extensions (in /System/Library/Extensions) to make them the same as the Apple-supplied extensions.

If you are the only user (or the most important user) and want to maker sure that you can always save the view state, the safest way is to create a writable .DS_Store file in every directory of a tree. For example, you can modify the /Applications tree with the three commands:

sudo find /Applications -type d -exec touch '{}/.DS_Store' ;
sudo find /Applications -name .DS_Store -exec chown yourname '{}' ;
sudo find /Applications -name .DS_Store -exec chmod 644 '{}' ;

You must type each command on a single line and substitute your user name for yourname. The result is that only you can write the files, although other users with write access to the directory tree can replace them.

Forced default

If you want to force all the directories in a tree to open in the default window view, there are three problems:

The procedure you must use is to eject the volume, type the following two commands (shown for the /Applications tree), then create the .DS_Store files with the three commands shown above. Be sure to visit each directory with the OS X Finder before visiting it with the OS 9 Finder (or just don't go exploring in OS 9, at all).

sudo find /Applications -exec SetFile -a i '{}' ;
sudo find /Applications -name .DS_Store -delete

These commands clear all the Inited attributes and remove all the .DS_Store files. They require many minutes to execute.

Applescript to the rescue?

Apple provides a drop script on their Finder Toolbar Scripts page, which you can examine with Script Editor. Inside, there is code to set window options. Will this let you batch fix problems? Maybe, but Finder scripting is incomplete in version 10.2.4; you cannot set:

As always, if permissions do not allow writing the .DS_Store file, the settings will quietly disappear at log out. Also, you will lose the settings if you relaunch the Finder before you eject or log out.

How can Apple fix this mess?

Although completely deterministic, the bizarre complexity of window states isn't Mac-like; it's more like something that came from the Beast of Redmond. Here's some advice for Apple:

  1. Leave the OS 9 world behind. Don't use the OS 9 Inited flag and icon positions; that just causes confusion. When .DS_Store is missing, create it with the default view.
  2. Drop the toolbar visibility hack. It just tricks users into thinking they have set the visibility state when they haven't.
  3. Make the default options explicit. The default view options are unlike the custom view options and need their own menu item. (They are per user.)
  4. Remember that other users are annoying. Consider adding a checkbox to the default options to "Ignore view options set by another user."
  5. Let the default options control toolbar visibility. Add radio buttons for "Always show toolbars," "Always hide toolbars," "Show toolbars by default," and "Hide toolbars by default." The "always" options make the effect of a window's toolbar visibility control only last until the window is closed.
  6. Make the custom view options informative. The options window should check file permissions and have a message area that says "changes will be lost when you log out" if the Finder cannot save the changes.
  7. Allow overriding permissions. Add an "override permissions if necessary" checkbox to the custom view options. When checked, if permissions are wrong, ask the user to enter the administrative password to force the creation of a .DS_Store file.
  8. Allow mass changes. Add an "Apply to enclosed items" button to the custom view options (overriding permissions if the user wishes).
  9. Write out the options promptly. Don't wait for an eject or log out to write the .DS_Store files.
  10. Consider dropping the open window log out state. It adds complexity and all the other applications have closed their windows.
  11. Make all the options scriptable. Check the file permissions and report an error if the changes cannot be saved.

Comments (52)


Mac OS X Hints
http://hints.macworld.com/article.php?story=20030305025744788