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:
- The state of open windows when you log out, which causes them to reopen when you log back in.
- The default "All windows" view options.
- The file icon locations and file comment text.
- The custom "This window only" view options and the position and size of the window.
- 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:
- You will lose all your "Get Info" comments.
- All the directories will initially have visible toolbars.
- If you go back to the OS 9 Finder, all icons will be arranged in their default positions.
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:
- the text size or location of labels,
- the toolbar visibility,
- the custom/default view option (Applescript sets it to custom),
- the window background.
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:
- Leave the OS 9 world behind. Don't use the OS 9 Inited flag
and icon positions; that just causes confusion. When
.DS_Storeis missing, create it with the default view. - Drop the toolbar visibility hack. It just tricks users into thinking they have set the visibility state when they haven't.
- 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.)
- Remember that other users are annoying. Consider adding a checkbox to the default options to "Ignore view options set by another user."
- 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.
- 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.
- 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.
- Allow mass changes. Add an "Apply to enclosed items" button to the custom view options (overriding permissions if the user wishes).
- Write out the options promptly. Don't wait for an eject or
log out to write the
.DS_Storefiles. - Consider dropping the open window log out state. It adds complexity and all the other applications have closed their windows.
- Make all the options scriptable. Check the file permissions and report an error if the changes cannot be saved.
