Extremely annoying Finder window behavior

Click on the left pointing arrow at the top of the window. That goes back to the previous view for that window.

I can confirm that this happens exactly as described. The "desktop" window contains the expected desktop items.

Not so many years ago Xserve code confused FTP root and computer root with unfortunate security consequences.

Is it possible that in some way user root and computer root have now been confused?

Do other OSs do this?

Interesting point about root.

The Installers folder sitting inside the hard drive is not located in a good location. You want it at bare minimum to be located in your Applications folder, if there isn't one there. Though I can't confirm that Quark doesn't already use a root installed Installers folder. That might be something you need to take up with Quark tech support if you find Quark fails to work after moving it.

This is unrelated to Quark. I repeated the initially reported quirk with empty folders. You can easily try it yourself.

I also have an installers folder at disk root as I do not want to back it up as often as my home folder. I had not noticed this quirk before but it definitely exists.

I fully agree with you and think it should be reported as a bug. It is inconvenient and counterintuitive.

Jack,

There is a very good reason why this happens. And no, it cannot be changed. The Finder is being more and more brought into compatibility with the UNIX underpinnings. One aspect of this is that, within any Finder window, navigation is tied to the full path, UNIX style.

You are viewing the contents of a folder which is sitting on your Desktop, with a path of Users/HOME/Desktop/The_Folder. When you move the folder you are viewing to some other location within the file system, you have basically moved it out of the Finder window's path. The window merely moves one directory "up" in the path. In short, it now shows the contents of your Desktop Folder.

You might not like it, in this instance, but there are far more implications that just this one "quirk." Incidentally, this behavior is the same regardless of the current view.

Scott

I don't fully understand this. Can you define 'Finder's path' in relation to the following?

/Volumes/Volume-A/Users/user-name/test-folder

Are you saying that this will happen with all open folders that are moved?

Neville,

Are you saying that this will happen with all open folders that are moved?

Yes.

/Volumes/Volume-A/Users/user-name/test-folder

I'm not sure what you're looking for here. You have already defined the path. If you are viewing the contents of "test-folder," and you move it to another location entirely, the Finder window still has a path of /Volumes/Volume-A/Users/user-name. By moving the folder "test-folder," you have moved it out of that particular Finder window's path.

Scott

Nice rationalization of a GUI flaw. Except it doesn't even bear any resemblance to what happens on the command line either.

TextEdit got smarter in Leopard and recognizes when the file associated with an open document is moved. And Finder got more stupid.

From a usability perspective, I could understand if a window's view should change if the folder whose contents it is displaying is moved to the "Trash", but otherwise, why shouldn't it update its path and retain the view of the contents?

If this is the most serious problem you ever encounter with the Finder then you are a very lucky person.

biovizier,

biovizier wrote:
Nice rationalization of a GUI flaw. Except it doesn't even bear any resemblance to what happens on the command line either.

It's not a rationalization, it is just a description of how the Finder window behaves. It just "is." And I didn't suggest any resemblance to the command line, although I think I would tend to disagree with your statement. In fact, the command line works exactly the same as the Finder, only the Finder is smarter about it. If you cd to a directory, then change that directory's location, the command line will happily report the original path all day via pwd. In spite of the fact that the reported path no longer exists. At least the Finder is smart enough to move "up" the path to the next nearest location.

I didn't say I thought this was the greatest thing since sliced bread, either. Again, it just "is." I do, however, assume that there is probably a very good reason why this behavior now exists. I've just tried to clarify what is happening when a Finder-viewed directory is moved, and provide at least a little bit of the "why."

Of course, I could be wrong in my assumption that there are benefits, somewhere. Either way, I'm not terribly bothered by it. I'm happy to adapt my habits to whatever behaviors the Finder happens to exhibit, as long as it works.

Scott

I still think somebody should report it as a bug and get it looked at.

Visit:

http://bugreporter.apple.com/

after signing up for the free online Developer program.

I don't see it as a bug, but perhaps you can suggest it as an System Preference enhancement request for those who don't desire it.

..." It's not a rationalization"...
..." I didn't suggest any resemblance to the command line"...

If you say so, but these comments left a different impression.
..." There is a very good reason why this happens"...
..." The Finder is being more and more brought into compatibility with the UNIX underpinnings."...

..." If you cd to a directory, then change that directory's location, the command line will happily report the original path all day via pwd."...

That's a quirk of ' pwd', which its ' man' page alludes to, although it seems to be calling it a limitation of ' dirs' rather than one of its own.

Instead of ' pwd', try a ' touch' or ' mkdir' after moving the folder, or a ' cd ..' and you will see that you were indeed still "in" the folder, in its new location. Unlike the "Finder", the shell doesn't dump you in the folder's original parent the instant of the move, nor do the files created by ' touch' (or ' mkdir') get created there as might happen with the "Finder" if you didn't happen to have noticed that the window contents had changed. The actual working directory is still the folder to which you originally changed to - the one you wanted to be "in", in its new location.

..." I do, however, assume that there is probably a very good reason why this behavior now exists."...

Perhaps. But sometimes, Apple just mangles it. Look at other things in Leopard that received arbitrary changes such as "Get Info", permissions repair, or pretty much the entire "Spotlight" GUI. It would be difficult to argue that the current versions in their current state are better than what they replaced. If we sit back and just accept anything they come up with assuming they know best, even if the feature is inferior, pretty soon we will be stuck with an inferior OS.