Lion Keeps Re-arranging my Folders

Just another thought.

There seems to be a myriad of ways to arrange the desktop, and if there are different settings, the system may get confused. Take a look at this:

In a desktop folder window, on the far left solumn, "favourites" the top item is desktop. The icons on the top bar include ACTION. Clicking this gives yet another access to ARRANGE BY... This should be set to NONE. I know that altering one setting somewhere should change every instance but ....

Then go down to ALL MY FILES.....ARRANGE BY.. the default would appear to KIND - try setting this to NONE as well (After all, who would ever want to list All the Files on their computer)

Thanks for your post.

There _are_ a lot of ways of arranging the desktop, as there definitely should be, and a number of ways of controlling the arrangement. And the mechanisms are obscure to the typical user. All of which can lead us to develop superstitions about the cause and how to fix this problem.

What triggers icon mal-rearrangement? The only suggestions I've seen is that navigating in Save dialogs or similar is a trigger. Since I can't imagine any way exercising those dialogs affect icon arrangements, I'm classifying this as a superstition for the time being.

Fixes? People have suggested removing com.apple.desktop.plist and/or .DS_Store as a fix. This prompts the Finder to recreate these files.

I find the content of com.apple.desktop.plist is visible in a generally understandable format if I double-click this file with the developer tools loaded. The file opens in XCODE and I can browse through the various keys (preference items) and their value (current setting). There's some interesting stuff there, as far as I can understand the information, but I haven't seen anything related to icon arrangement. Based on this, it seems that removing this file can be classified as a superstitious solution.

All the information I've seen points at icon arrangement being controlled solely by the contents of .DS_Store. I'm guessing that .DS_Store is cached in memory to speed up Finder operations. As I've posted earlier in this thread, I've seen some evidence that in 10.7 .DS_Store is autosaved and restored, say, when the current version is detected as inconsistent. Again, I think these factors promote superstitious solutions.

Based on what I've seen so far, I'm thinking that there may be some cases in which the settings we users see and the actual settings acted upon by the Finder to arrange the icons are different. This could occur as a result of installing 10.7 if the options and/or the methods of making the settings changed, requiring conversion(s) to .DS_Store contents. It seems possible that some of our settings in 10.6 didn't get properly converted to the new 10.7 internal representation. Or, conversion or not, with all these alternatives, it seems quite possible that some combinations don't get properly represented. In sum: either internal or external inconsistencies occur.

Here's what I'm going to do in the day few days: I'm going to _try_ to work normally while keeping an eye out for mal-rearranged windows. I might get some new ideas about triggers. I'm going to test the "inconsistency" theory by making some quick adjustments to windows I find mal-rearranged: First, I'm going to use the View Options settings, particularly "Arrange by" and "Sort by" to display the window in some radically different format to what I usually use. Then I'm going to return the settings to the ones I want: "none" and "none". Next, I'll quickly rearrange the icons to roughly the way I want them. Then I'll close that window. Later on, periodically, I'll reopen and check the icon arrangement in that folder.

In other words, I'm not going to trust the settings I find in View Options, especially if I find a mal-rearranged window with "none" and "none" settings. I can hope that first entering completely different settings and then entering "none" and "none" has a chance of making these settings completely consistent.

I'm also going to look for new information to prove myself wrong. For example, I should not be so quick to regard Save-dialog triggering as a superstition. When I save a _new _file to a folder that is set to appear in icon view,the new file icon appears somewhere "new" and not overlapping an existing icon, right? Presumably that changes the information .DS_Store. Could this disrupt the locations of other icons or the internal settings for "Arrange by" and "Sort by"? Could be. If so, then I can think of an awkward work-around that might serve until the problem is fixed.

Exactly same thing here with my two different Macs!

Usually this happens if I open or save something through a program (where documents are sorted by list instead of folders - I mean text). Next time after this when I go to Documents f.ex. everything is alphabetically arranged again - not in MY order. Yes. I tried all of the options of cmd+j and the finder window selections too - it's a bug.

This all is a puzzlement. There is one thing I can repeat. I normally have my system drive in icon view format with a particular arrangement. "Always open in icon view" is set.

I open Photoshop (CS5) and go to File/Open. I use column view.

I click on my system drive in the side bar and any entry in the first column.

I then double click on the hard disk icon on the desktop and it comes up in column view and "Always open in column view" is now set. The column view is not quite right. It is has the items in my hard drive on the left of the window. Other columns do not appear unless I click on an entry.

I change the column view to icon view. The "Always save..." automatically reverts to the original value and I am back where I started.

I return to PS and click a first column entry in the Open window and double clicking on the system disk agains shows the column view.

When I leave PS, the column view for my system drive persists until I change it back to icon view. The icon positions are preserved.

A similar PS experiment where I actually open something and then Save or Save as will typically scramble the hard drive icons in addition to going to column view.

Even stranger, if I repeat the experiment with BBEdit, a text editor, everything works properly.

Another simple text editor, TextEdit, did not seem to cause any problems.

Finally, I tried the same tests with Page, an Apple application. The behavior was the same as PS including scrambling icon locations if I did a Save.

Microsoft Word did not change views with just browsing but some icons were moved after saving a file.

I postulate that it is the browsing during an Open, Save, Save As, etc. that does unexpected things to folder icon settings. I can say with certainty, that the .DS_Store folder is changed even in cases where I merely look around and not actually save anything. After things go bad, I just restore my .DS_Store files from previously saved copies.

I would also conclude that the association of browsing with odd behavior is likely more than a superstition since a single click in a browser can change the appearance of the icons in a folder. This varies with applications so some applications may have not been fixed to work with Lion. The scrambling of icon locations with a Save occurred with all applications except for two small text editors.

Thanks for your post.

As far as I know, you are the only one who has come up with a repeatable demo of this issue. Definitely worth following-up: I'll try to duplicate your results of shifting views due to simple browsing in Open dialogs. We can call this "Save Dialog View Instability" (SDVI) until someone comes up with a better term. (This term doesn't clearly cover Open dialogs for example.)

Trying TextEdit [v1.7 (288)]… Yes, I see it. (I use my HD root directory as a test case, too.) Here's the procedure and results:

0. Finder: View --> "Show View Options".

1. Finder: Open HD root folder, observe "icon view", my customary icon arrangement, and "aways open to icon view" in "View Options"

2. Finder: Close HD root folder.

3. TextEdit: File--> Open

4. Open Dialog: Click on HD at left

5. Open Dialog: Click on "Column View" at top

6. Open Dialog: Click on some folder in HD

7. Finder: Open HD root folder. SDVI: The view is now columns and "always open" is set to column view.

I note:

o Step #2 is necessary; the issue doesn't affect an already-open window.

o If I skip step #6 there is no change.

o This only occurs with respect to column view. Can't get a change to Cover Flow, for example.

o Clicking the icon view in the open HD root folder restores my customary icon arrangement and checks "always open in icon view". (So this is only part-way to icon mal-rearrangement.)

o Strange that it occurs for me in Text Edit and not for you. Maybe a version difference.?

Checking with some other versions and apps:

--A quick, similar experiment with TextEdit [v1.5 (244)] on a 10.5.8 system: no problem.

--A quick, similar experiment with TextEdit [v1.6 (264)] pm a 10.6.8 system: no problem.

--A quick, similar experiment with Pages [old: v1.7 (288)] on 10.7 : partly rearranged the icons, but I can't seem to repeat this.

I think it is slightly arguable that changing the view of a folder in an open dialog actually _ought_ to change the view when the folder is opened in Finder. ("Save Dialog View Consistency"?) In other words, this is a feature. But I'd expect this to be consistent and reversible with all the view types, which I did not find. So, yes, this looks like a bug.

The second step is reproducing icon mal-rearrangement. Probably it would be best if we could identify a piece of software distributed as part of 10.7 that invariably triggers mal-rearrangement. So far, I haven't found one. Second best: the current latest version of a very commonly used app. No luck so far on that, either.

Now that I've seen a repeatable error that almost certainly is due problems with .DS_Store, it seems very likely to me that we will eventually find an app that reliably triggers icon mal-reorganization. What's going on? I'll speculate wildly: Maybe the 10.7 implementors had a goal of coordinating view control in Finder windows with view control in Save Dialogs, but they didn't finish the job. Or, the two viewing situations were uncoordinated and were intended to continue being uncoordinated, but someone slipped and --maybe making something as simple as a naming error--partially coordinated the two.

Do either explanations suggest a workaround? Maybe. Possibly it will help to use only the simple, unexpanded Save dialogs, accepting the default directory or picking one from the Where: list. If the Mac doesn't try to display directory contents in one of the four views, maybe that will be enough. Open dialogs unavoidably display all the files in the selected directory, but… it might be effective to never use Open dialogs for existing files. Instead, navigate in the Finder to view a file you want to open, and simply drag-and-drop the file icon to the app's icon, or an alias of it, or the app's dock icon. Another approach: Are there OS add-ins that provide alternate Open and Save dialogs? (Anyone?)

I wouldn't waste your time fighting with this, it's almost certainly a 10.7 bug with the file system. They are not corrupted folders, corrupted .DS_Store files, or group/permission problems. It's simply that saving a file into a folder appears to wipe the .DS_Store clean, and then the folder is rearranged alphbetically.

I've also seen a save action wipe the .DS_Store for an enclosing folder and the folder above that. I'm also pretty sure I've seen a folder dragged into another, inherit the enclosing folder's view attributes (changing from icon to list and closing the tool and side bars).

I've filed an official bug with Apple's bug reporting system.

Thank you, Jyri. Best news yet! I agree it's simply a bug, and I'm sure Apple is aware of it from their own testing. It does seem to be be related to saving files. And it usually wipes out folder settings for a number of other folders when it occurs. From a test I did today, it does not change the modification date of the enclosed .DS_Store files though. I've run into something like this in the past (maybe Leopard) when installing/updating a certain application, which was eventiually corrected. I'd love to know which settings file(s) is/are being corrupted so I could keep backups.

Bill

Thanks for your post and for filing an official bug report.

You seem very confident in your analysis. Might I ask for a few more details why you are certain this is a 10.7 filesystem bug, as opposed to damage to the structure/content of .DS_Store? The evidence I've seen could indicate variable/incremental damage to .DS_Store. How do you account for the view-change problem we've been discussing that occurs with no save at all, just browsing?

If you are correct, the implications are pretty scary, especially if there's no fix right away. Unless you have evidence that this bug is clearly specific to wiping out .DS_Store ONLY (how would that work?) maybe all of us experiencing this problem ought to fall back to 10.6.x immediately.

By "10.7 file system bug" I mean that everyone seeing it is using 10.7, and it seems pretty clear that the act of saving something - or even moving something - in the file system is causing some sort of write to the .DS_Store files. The write may be "normal" except that whatever code is doing the writing now is likely doing it wrong.

I've seen the view-change problem occur to a folder that is enclosing one two layers down in which something changed. Note that merely browsing alters the "Last opened" metadata which I assume is also in the DS_Store.

In 10.7 there's a whole new facility for document management that occurs transparently, including autosave. With all these things going on, it's likely that lots of things are getting altered when we are seemingly doing nothing to the file system. If these all touch DS_Store files in some way, like writing some default everyplace that is touched, it would manifest in all these troubles.

Fingers-crossed, I don't think this puts data at risk, but it sure is annoying for those of us that depend on specific layouts of folders for workflow. I'm not upgrading my desktop machine until this is fixed, that's for sure. There are way too many things in particular arrangement there.

On a related topic, who else is annoyed by the fact that new folders are always sized slightly too small, if the sidebar is there by default? I wish there was a global setting for "all new windows this wide." Not that OS X would be able to remember it right now. But with the lost settings, I'm seeing a lot of windows revert back to that default size. Ugh.

I am not sure if this is related, but in Lion 10.7, if you rename a file by capitalising any letter then the file size becomes Zero bytes and the file is corrupted!

For example, rename "my file.rtf" to "My file.rtf"

It does this only if the file has existed for say 10 minutes, and not if you create it new and then change it immediately.

This kind of bug is a serious worry, can we trust this new filesystem?

Wow! Holy bleep I can confirm that here on an RTF test file I created last night. That's frightening.

I've also registered a bug report on this one.

coolas wrote:

I am not sure if this is related, but in Lion 10.7, if you rename a file by capitalising any letter then the file size becomes Zero bytes and the file is corrupted!

I've experienced the same bug, but don't believe the file is corrupted. Do a Get Info on the file and you will see it's true size.

Get Info on the file confirms the file size is zero bytes. Also, opening the file reveals the data is gone!

Further, it is not a Finder issue, if you use mv to rename a file in Terminal, it also zaps the file to zero bytes.

Looks like I'm back on my Windows XP PC until Apple fix Lion's filesystem 😟

Here's a theory. Perhaps the same mechanism that is zero-ing out these test files, in some form is doing the same to .DS_Store files, which are then replaced by brand new files with system defaults. Then icon placement, views, and everything are instantly changed.