Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Explaining the Finder's view options and toolbar visibility Desktop

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:

  • 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:

  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.
    •    
  • Currently 3.50 / 5
  You rated: 4 / 5 (8 votes cast)
 
[68,699 views]  

Explaining the Finder's view options and toolbar visibility | 52 comments | Create New Account
Click here to return to the 'Explaining the Finder's view options and toolbar visibility' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Explaining the Finder's view options and toolbar visibility
Authored by: eno on Mar 07, '03 10:24:32AM

I can't believe you just did that....



[ Reply to This | # ]
I'm underemployed...
Authored by: noworryz on Mar 10, '03 10:55:54AM

 

I'm underemployed right now, does it show?

 

 

[ Reply to This | # ]

Why .DS_Store files?
Authored by: biscuit on Mar 07, '03 10:59:18AM

Thanks for the informative read, I'm glad someone knows how it all works.

It makes me think though, are .DS_Store files really needed? Shouldn't that sort of information be held in the filesystem anyway?

Who knows, maybe in 10.3...

biscuit



[ Reply to This | # ]
Why .DS_Store files?
Authored by: j-beda on Mar 07, '03 03:27:11PM

I think they are designed to work on UFS disks, though I don't know why they are used on HFS ones.



[ Reply to This | # ]
Explaining the Finder's view options and toolbar visibility
Authored by: diamondsw on Mar 07, '03 11:06:36AM

One more thing you can't script - whether or not a window has thumbnail icons turned on. :(



[ Reply to This | # ]
Outstanding Hint!
Authored by: dm2243 on Mar 07, '03 11:08:57AM

I had given up hope understanding the Finder. Thanks!



[ Reply to This | # ]
Explaining the Finder's view options and toolbar visibility
Authored by: Durandal on Mar 07, '03 11:50:41AM

Yet another piece of evidence on the growing heap showing that the Finder is a complete piece of crap. It doesn't even use proper Unix paths; it uses OS 9 colons and doesn't respect mount points. Pure idiocy.

Just so everyone knows, the Finder "won" the "Worst OS X Application" poll we ran over at Ars.

---
Damien Sorresso



[ Reply to This | # ]
Explaining the Finder's view options and toolbar visibility
Authored by: b3uk on Mar 07, '03 01:06:31PM

What I really want to see Apple implement is a set of saved views, so that I can have a standard view for normal folders, and (for example) apply a different 'thumbnail view' to every folder I keep pictures in (without having the set the individual options each and every time).

---
"Do it now. Today will be yesterday tomorrow"
- Talking Moose



[ Reply to This | # ]
Explaining the Finder's view options and toolbar visibility
Authored by: ssevenup on Mar 07, '03 01:35:15PM

It makes it sound like the Finder was written by a defense contractor ;-) Only a government contract could result in such a friggen mess.

---
Mark Moorcroft
ELORET Corp. - NASA/Ames RC
Sys. Admin.



[ Reply to This | # ]
Explaining the Finder's view options and toolbar visibility
Authored by: baltwo on Mar 15, '03 03:08:04AM

And Mark Moorcroft waxed eloquently, "It makes it sound like the Finder was written by a defense contractor ;-) Only a government contract could result in such a friggen mess"

Actually, it sounds like a defense contractor developed the Finder to the rigid, redundant, and mind-boggling specifications dictated by Government procurement officers.

Retired defense contractor



[ Reply to This | # ]
Explaining the Finder's view options and toolbar visibility
Authored by: mm2270 on Mar 07, '03 03:45:20PM

I have to agree, sadly. I've been battling with OS X's erratic and frustrating Finder Window and views behaviour since the beta days, and it has not improved much. In fact, it arguably got worse in Jaguar with the ability to show the info tags beneath icons. Turning that on, at least for me, seems to wreak total havoc on my icon views!

And I second another user's question above about whether or not that damned .DS_Store file is really necessary!? With all of Apple's push to make OS X a friendly network citizen, they've probably caused more damage by using the DS_Store file because of how OS X craps in every directory it touches, even Windows servers and machines. I can practically hear the cursing of Wintel Admins around the globe as they go around deleting these things! Apple really needs to find another way of saving window preferences without laying lose stupid mouse droppings in every directory, and they really need to fix the Finder as a whole, 'cause as you said, it's really the worst OS X app that ships with the OS.



[ Reply to This | # ]
Explaining the Finder's view options and toolbar visibility
Authored by: Cantus on May 22, '03 02:19:24AM

Oh man, I couldn't have said this better!!!



[ Reply to This | # ]
Explaig t Fir's viw otis a tolr vsbit
Authored by: dave1212 on Mar 07, '03 07:15:29PM

fsck.. this is so sad.. yes, we're power users, yes we need a better finder (sometimes) than the one apple provides..

but is this a reason to biatch to this amount? voting about it being the worst of OS X? What a load of crap.. if you really need a better finder, use path finder. If not, shut the fudge up already.

Some of us don't want apple fscking with the finder any more than they already have.

Worst of OS X.. check out perversiontracker if you want to see useless apps. What would we have used all this time if not for the finder? If you want something better, either build it, buy it, or submit your ideas to apple. Biatching about it here does nothing unless you post some tips or tricks to make whatever it is you're biatching about better.

This tip is a great resource, thanks for taking the time to sort it all out!


---
______

[ IE Toolbar Icons, Desktop Picures, Free MP3s ]
http://www.paulprobert.com/



[ Reply to This | # ]
Explaig t Fir's viw otis a tolr vsbit
Authored by: Cantus on May 22, '03 02:21:54AM

Sometimes it is necessary to bi*ch to provoke changes.



[ Reply to This | # ]
Explaig t Fir's viw otis a tolr vsbit
Authored by: QonoS on Nov 10, '03 09:02:18PM

It's always fun to read someone bi*ch and moan about how other people are b*ching and moaning.



[ Reply to This | # ]
Explaining the Finder's view options and toolbar visibility
Authored by: BMarsh on Oct 07, '04 06:57:14PM

Just ran across this article & comments...

The finder uses colon's because that is what HFS/HFS+ uses

(no one else filled in this reason why the finder does this, when the finder is dealing with other file systems, it translates to the necessary path indicator)



[ Reply to This | # ]
View Options for "Computer"
Authored by: blukens on Mar 07, '03 03:00:45PM
Great article!

I wrote up some information, at http://www.personal.kent.edu/~blukens/viewoptions.html, describing a few other peculiarities of the Finder's View Options. Specifically, I describe how to make the layout in the top level "Computer" window stick. Perhaps it's common knowledge, but I couldn't find much on that subject. Anyway, check it out if you're interested.

[ Reply to This | # ]

View Options for "Computer"
Authored by: dave1212 on Mar 07, '03 07:19:40PM

Very good read.. everyone should check this out.

Twas helpful as well.

---
______

[ IE Toolbar Icons, Desktop Picures, Free MP3s ]
http://www.paulprobert.com/



[ Reply to This | # ]
View Options for "Computer"
Authored by: rusto on Mar 09, '03 04:44:18PM

Finally, I've got the "Computer" window's view prefs set to my satisfaction, thanks!



[ Reply to This | # ]
Explaining the Finder's view options and toolbar visibility
Authored by: bluehz on Mar 07, '03 05:45:23PM

Not sure if this is technically part of the Finder issue going on here - but what bugs me more than the Finder, are the Open, Save, Save As.... type dialogs. Those things seem to have a mind of their own... jumping all overthe place, erratic keyboard reponses, etc. I have given up on even trying to understand that. First thing I do when I set someone up with a new OS X install - apologize for the wonkiness in the dialogs and tell them it should be fixed soon. Well soon has turned into over two years now and still waiting.....

On the good side of this... the oddities of OS X GUI have pushed me into learning more and more UNIX and CLI. I almost preer to navigate, and do whatever possible using the CLI. So much faster and predictable. Of course thats the beauty fo OS X - I can have my CLI when I want and switch to GUI if I need be.



[ Reply to This | # ]
Explaining the Finder's view options and toolbar visibility
Authored by: GaelicWizard on Mar 07, '03 08:35:30PM
Re: Explaining the Finder's view options and toolbar visibility
Authored by: eo on Mar 07, '03 10:23:45PM
Second that! Never have I felt the need for such an explanation of how Path Finder handles various situations.

[ Reply to This | # ]
Well PathFinder has UI glitches too
Authored by: janpeeters on Mar 08, '03 07:20:34AM

Illogical for example is that you can't decide where to place your icons on a desktop when you have align to grid 'on'. It just places them by name e.g. on the right side of the screen. Why isn't there something inbetween. I get crazy if I can't place my icons grouped per categorie on my screen but snapped on a grid.

Next problem is the dropdown folders in column view, why use columnview (which is horizontal) if you want folders to drop down in the same column (which is vertical). Give that option a modifier key but not by default.

Besides that the anti-aliasing on the desktop is crapy compared to Apple's antialiasing.

For the rest a great app, but sure they have to build in more customization options.

Jan Peeters



[ Reply to This | # ]
Well PathFinder has UI glitches too
Authored by: GaelicWizard on Mar 09, '03 06:43:06PM

Finder: Won't change unless Steve wants it to.
Path Finder: Got complaints? E-Mail them to the author! He'll fix it!

---

Pell



[ Reply to This | # ]
Well PathFinder has UI glitches too
Authored by: Ptero-4 on Nov 08, '05 08:26:05PM

Actually the Finder iss good for "browser" mode but craps out when you try to use it in spatial mode. Path Finder have a better spatial/browser mode selector (it doesn't swap modes randomly). But PathFinder have some glitches. It's CD burner is crap and at anything past 2x is a sure coaster, it's archiver is as crap as the Finder one (it doesn't treat archives as folders, which Allume Zip Magic and Konqueror's built-in archiver do) and it's go a bug that if you set PF to spatial mode, the view to icon view and tell it to open each folder in a new window, when you doubleclick in a folder its window opens behind it's parent folder window. If I were you I would install Konqueror b/c Apple will never fix the Finder and M$ in the name of "piracy prevention" patched cocoa to put intentional bugs that would make building an spatial filebrowser imposible (the folder view bug in PF is caused by those bugs placed by M$ in cocoa). The reason for this is to make OS X seem crap for the users (remember that OS X lacks a start menu and since this means that the users is goin; to have to use the filemanager a lot obviously M$ is goin' against everything that makes the OS X filemanager.)



[ Reply to This | # ]
Explaining the Finder's view options and toolbar visibility
Authored by: punkmanandy on Mar 08, '03 12:37:26AM

If you have the hack for a "Quit" menu item in the Finder installed, then when you use that to close the finder, these control files get written.

As long as the Finder exits cleanly, then the states will be saved. if a crash or a force quit terminates it, then you will lose these changes.



[ Reply to This | # ]
Explaining the Finder's view options and toolbar visibility
Authored by: QonoS on Nov 10, '03 08:59:42PM

Quote: "If you have the hack for a "Quit" menu item in the Finder installed, then when you use that to close the finder, these control files get written."

TinkerTool (www.bresink.de) performs this hack nicely. No doubt there are other ways.



[ Reply to This | # ]
The author responds
Authored by: noworryz on Mar 08, '03 11:42:23AM

The article author responds to your comments:

Thank you for all your kind comments!

Several people have suggested getting rid of .DS_Store files or using Path Finder, which avoids them. What this idea implies is eliminating a key Finder feature: the ability to shuffle icons within a folder the same way you shuffle sheets of paper on a desk. It's the heart of the desktop metaphor.

Not everyone uses this feature. Unix users probably only use list view. Windows users probably have been mind-raped too many times to care. However, many Mac users, especially those in the graphic arts industry, are passionate about how they organize their icons. They shuffle icons to provide information about workflow, or file importance, or to make an artistic arrangement. They would crucify Apple if the feature were removed.

So Apple really didn't have a choice whether or not to save the location of each icon. The only question is how best to do it in the the new, multi-user world of OS X. Let's look at a few possibilities:

  1. Use the same concept as OS 9, without thinking through the implications of multiple users or permissions. This is the method Apple chose.
  2. Do it as above but fix the permissions issues. This is what I suggested -- minimal changes to make it bearable.
  3. Create a separate state file for each user in each directory. This is a possibility but, whoa, that's a lot of files, especially on remote file servers.
  4. Use a big database in the user's Home directory tree, which saves the state of wherever they've been. This might work, but what do you do about removable media? What happens when a CD is inserted?

As you can see, every method is a compromise. Apple made a decision to go with the .DS_Store files, probably for historical reasons. Their implementation leaves something to be desired, as many of you have stated. I hope they spend more time thinking about the issues to make it easier for the users.

[
Reply to This | # ]

split the difference
Authored by: sevenoftoine on Mar 08, '03 03:32:31PM

If you have read-only media, you could have a .DS_Store there to represent a view of the contents, and then keep a modified version of the same under your home directory. That way, you keep the integrity of the presentation as defined by the creator of the files, but if you go ahead and move them around, your homedir version now overrides the original.

-- Antoine Durr



[ Reply to This | # ]
Another solution
Authored by: mj on Mar 08, '03 05:52:04PM

What seems like a good solution to me is to do something similiar to the .DS_Store files, but much more cleanly. Let all view information be stored in a .DS_Store file that is located in the highest directory in which you have write access, or if you have a home directory on the disk, to somewhere in your prefs folder. Then when a directory or file is copied to another disk, that information can be merged rather easily into the appropriate .DS_Store on the other disk. To find the view info, just traverse the directory tree to the root and use the first .DS_Store relevant.

Something else that could be done instead of/in addition to this is to store info for other disks in your home prefs folder, and have this info perged every so often, though for disks that you really do use more than once, just rarely, this would have an unsettling effect, but in this case, the .DS_Store files idea I mentioned above would kick in.



[ Reply to This | # ]
Another solution
Authored by: punkmanandy on Mar 09, '03 03:59:12PM

what happens if it is a shared volume that can be accessed at several different points in the directory hierarchy, ie a users home folder?



[ Reply to This | # ]
Another solution
Authored by: GaelicWizard on Mar 09, '03 06:47:25PM

This all depends on the user using Finder. Most (not all) of the Finder-set settings in the .DS_Store files are retained whether I move the folder in Path Finder or in the terminal. But if there is no *real* file in a folder, then unless i use the finder to move it ALL my settings are lost for that folder.

---

Pell



[ Reply to This | # ]
Interesting ideas, people...
Authored by: noworryz on Mar 09, '03 03:20:23PM

You two have suggested interesting concepts:

  1. Use a database in each user's home directory that overrides .DS_Store files.
  2. Compress .DS_Store files to the top level on each volume.

The big issue, though, is how to let the user understand and control whether or not the .DS_Store file (or files) gets written to a removable volume, especially when the permissions do not allow it.

Perhaps when the user ejects a removable volume, the Finder could ask "Do you want to make the folder view changes you made to YOURVOL the default for all users?" It would then ask for the admin password if the permissions were wrong.

--Glenn

[ Reply to This | # ]

Explaining the Finder's view options and toolbar visibility
Authored by: psu13 on Mar 08, '03 10:17:13PM

I'm pretty sure the custom view information for a given folder is not stored in the .DS_Store file of the parent.

It's easy enough to verify this by changing view info and logging out and noting the modifications of the .DS_Store files in the area.

Just try it with your home folder.



[ Reply to This | # ]
It's best to try it before posting--I did.
Authored by: noworryz on Mar 09, '03 01:19:00AM

I'll stand by my description; it was the result of about 18 hours of experiments. After reading this comment, I re-did the test to confirm that the view info (background, icon size, etc.) really is in the parent's .DS_Store file.

[ Reply to This | # ]

Explaining the Finder's view options and toolbar visibility
Authored by: Carbonide on Mar 09, '03 04:39:18AM

When trying the commands to set the DS_Store to writable I get a 'no terminating ";"' error although I 'm sure I typed the command exactly as shown.



[ Reply to This | # ]
You've discovered a site problem!
Authored by: noworryz on Mar 09, '03 01:23:41PM

There is supposed to be a backslash before the semicolon at the end of each line. I think Rob helpfully deleted the backslashes, which were in my original post (surrounded by PRE tags), maybe by putting them in CODE tags.

So here's the code again:

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 '{}' \;

And:

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

-- Glenn

[ Reply to This | # ]

You've discovered a site problem!
Authored by: rusto on Mar 09, '03 04:51:11PM
Perhaps a second backslash is needed to escape the first (if you don't see them here, well at least I tried!: 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 '{}' \;

[ Reply to This | # ]
You've discovered a site problem!
Authored by: rusto on Mar 09, '03 04:55:00PM
Hehe, something happened to the line feeds that time. You get the idea though. Last try:

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 '{}' \;


[ Reply to This | # ]
It looked OK in Preview. It's a SITE BUG!
Authored by: noworryz on Mar 09, '03 01:29:29PM

The problem is a site bug. The code looks OK when you preview it but when you post it, backslashes disappear!

I'll whine to robg.

[ Reply to This | # ]

It's a site feature!
Authored by: noworryz on Mar 09, '03 08:36:59PM

robg let me know that PRE tags (in angle brackets) aren't the way to insert code in a hint or comment. You have to use CODE tags in square brackets. Code tags in angle brackets are different: they just change the font.

I'm not sure why backslashes disappear in PRE-tagged sections, since the backslash is not an HTML special character; they just do. The site also interprets HTML character entities instead of passing them through.

[ Reply to This | # ]

Another solution?
Authored by: Phoenix1701 on Mar 09, '03 09:33:27AM

It seems to me the most logical (and simplest to implement) solution for this mess would be as follows:

If the filesystem is UFS, all bets are off. Do whatever you can with the little you have to work with, or just stop supporting UFS at all (why is it supported anyway?)

Otherwise, create a .DS_Store file in each user's home directory, containing custom view information for each folder the user has seen. Be sensible and use filesystem reference IDs rather than absolute paths, so the whole thing doesn't break when the user renames or moves a folder. If a .DS_Store file is present on a read-only volume, use it instead unless the main .DS_Store file already contains an explicit entry for that volume (to allow for spiffy disk images with custom backgrounds and positioning, etc). In all other cases, write data out to the (singular) .DS_Store as it changes rather than waiting for logout.

Can anyone find problems with that...? It works for multiple users, doesn't break read-only volumes, gets rid of the problem of Macs littering remote servers with rogue .DS_Store files, and doesn't depend on filesystem-specific metadata except reference IDs (which are such a good idea they really should always be there, UFS be damned). If you see a hole, perhaps we can fix it... otherwise, <a href="http://www.apple.com/macosx/feedback/">tell Apple!</a>



[ Reply to This | # ]
Couldn't understand your scheme
Authored by: noworryz on Mar 09, '03 01:46:00PM

I'm afraid I couldn't understand your scheme. If the .DS_Store files (actually new database files as was suggested in an earlier comment) are only written in the user's home directory, how would they get on read-only volumes? How do you set up a CD so it looks good?

I also don't understand your distinction between HFS+ and UFS, since they both use the same .DS_Store file, at present. Basically both file systems are treated the same, as far as the Finder is concerned, except when the .DS_Store files are missing.

-- Glenn

[ Reply to This | # ]

Couldn't understand your scheme
Authored by: Phoenix1701 on Mar 10, '03 05:41:45AM

Well, as for the question about CDs, the idea was that if the current folder is on a read-only volume, the Finder will look for a .DS_Store file in that directory first before referring to the global one in your home directory. Therefore, to make a CD look the same on all machines, just include a .DS_Store file on it. (Of course, you'd have to do this with some program other than the Finder... Disk Copy perhaps?)

In regards to the UFS/HFS+ issue, the reason I draw a distinction is because -- to my knowledge -- UFS does not support filesystem IDs for files. (If that's wrong, and Apple has just been using hard-coded paths for things for no reason whatsoever, someone on the Finder team needs to be throttled.) Therefore, the entire scheme I suggested would break on a UFS volume. :(



[ Reply to This | # ]
DS_Store files do have file names
Authored by: noworryz on Mar 10, '03 10:25:01AM

The .DS_Store files do have file names in them -- that's so they can work on UFS volumes. Furthermore, the characteristics of folders move with their names. You can prove this by renaming a folder in the terminal, creating a new one with the old name, and relaunching the terminal. The new folder you created will have the old folder's characteristics (background, etc.). The .DS_Store mechanism apparently does not use HFS+ file IDs at all.

The .DS_Store files do not have full paths names in them. There is no need, for the file names always refer to the files and folders in the same directory.

All this is easily verified using HexEdit and some simple experiments.

[ Reply to This | # ]

But what I really want to know is...
Authored by: eno on Mar 09, '03 10:07:27PM

... where (and how) is the information about a Finder window's background image stored?

I would like to be able to change images from the command line, but I can find no way to do it.



[ Reply to This | # ]
Sorry...
Authored by: noworryz on Mar 09, '03 11:52:58PM

A custom directory view's picture location is kept in the .DS_Store file in the directory's parent directory. As of March 2003, there are no tools to modify this file and no Applescript support for this option. The file format is Apple proprietary.

For the "all windows" default view, the information is in ~/Library/Preferences/com.apple.finder.plist. You could perhaps write a program to send the Finder a "Quit" Apple event, write this file, then re-start the Finder. (The file is in XML format.) It would be a lot of work and the result would be very intrusive to someone using the machine.

Probably your best option is to wait for better Finder Applescript support.



[ Reply to This | # ]

Toolbar state of Computer and Trash windows
Authored by: noworryz on Apr 06, '03 09:06:07PM

I was asked about the toolbar visibility state of the Computer and Trash windows (by someone who gave me a bad email return address).

The toolbar state of these windows is written at logout to the Finder's ~/Library/Preferences/com.apple.finder.plist file in the properties Root/ComputerOptions/ComputerToolbarVisible and Root/TrashOptions/TrashToolbarVisible.

However, the states are never used when the Finder creates the data structures for the windows when they are first opened -- an obvious bug that can be reported to Apple feedback. These windows always show the toolbar after you log in. (You can make the toolbars less obtrusive by turning off their icons in View/Customize toolbar.)

--Glenn

[ Reply to This | # ]

Explaining the Finder's view options and toolbar visibility
Authored by: cyrus713 on Apr 13, '03 01:54:59AM

What I want to know is if somehow the .DS_store file has become visable, how do you get rid of it or make it invisable again?



[ Reply to This | # ]
Explaining the Finder's view options and toolbar visibility
Authored by: carsten on May 22, '03 08:30:09PM
Try: Install TinkerTool. Turn off "Show hidden and system files", then quit and relaunch the Finder or log out and back in again. (TinkerTool is probably how the ".DS_Store" files were made visible on your machine in the first place, either by someone who had access to your computer, or by you and you just didn't realise it would have that effect. ;))

[ Reply to This | # ]
Explaining the Finder's view options and toolbar visibility
Authored by: KC Owen on Sep 30, '03 09:14:51PM

Yes, try onyX found here----------

http://www.titanium.free.fr/us/onyx/index.html



[ Reply to This | # ]
Explaining the Finder's view options and toolbar visibility
Authored by: fwpGreg on Aug 22, '03 08:34:12PM

I've tried everything listed here and still finder will not remember icons prefs or locations in any folder above my user home. I've changed onwer and group of DS_Store to (me) and to admin, neither had any affect. I've erased the contents of the DS_Store file. Nothing is working. I'm the only user, I'm always logged in as an admin.



[ Reply to This | # ]