Wow, this is really funny.

Nautilus used to work the way you are requesting. Then lots of people
reported that it was a bug, and we went to considerable lengths to
make it work the way it does now.

Now you are asking us to change it back.

I think we're going to have to think this through some more to figure
out a way to make everyone happy.

Darin,

This isn't that difficult.  If people want this to work differently to
how I have proposed that is fine, but it should *NOT* be the default
behaviour.

Moving around the file system in Nautilus should work exactly the same
way that it works in the terminal.  Nautilus - at the moment - does not.  

This is inconsistent and therefor confusing.  If I move up a
directory, and then back down, I should end up in the same directory.
 This is how it works at the command line (by default), and nobody is
complaining about this.  Nautilus should work in exactly the same way.

If people want nautilus to be inconsistent with the default behaviour
then this is fine, but make it a preference, and don't make it default.

Darin,

Ooops, chop the first paragraph of what I said above.  It comes over
sounding rude and pompous (which wasn't my intention) and it's not
needed anyway.  Soory if I offended anyone ;-]

Rodd

I have to concur with rod on this one. The current behavior just
totally negates the whole purpose of symlinks in unix. I would hope
that this change would be reverted so that Links(symlinks) behave
correctly in nautilus as they should in unix, instead of simply
placing the windows paradigm of "shortcuts" on unix. The current
behavior of symlinks in nautilus pretty much defeats the purpose of
them. The current behavior pretty could be achieved using .desktop
files. Symlinks however should behave like they do in the terminal...

I really want to bump the severity of this to normal. Louie?

yeah, I guess this really isn't an enhancement. Not sure I can see it
as a huge bug, though, either way.

I've stated this already, but I think it's worth pointing out again.

The current behaviour in nautilus isn't the same as the behavior at
the command line.  This creates a confusing situation.

Further, i would expect that if I go down a branch, I'd head up the
same branch when moving in the opposite direction.

I'll state it outright.  The current path navigation in nautilus is
busted.  It's unintuitive and inconsistent.

Here's an example.

If I have symlinks in my home directory that link to four or five
other directories elsewhere on the disks, this is because I want to
stay in my home directory.  If I wanted to be somewhere else on the
disk, I'd navigate to that point, and start there.  I can see why some
would argue that you can get to the home directory by pushing the back
button, so having the up button move to the actual link directory
might add functionality, but what it actually does is create confusion.

Created attachment 13368 [details] [review]
Deactivates translation of symlinks to their real location!

Created attachment 13369 [details] [review]
Sorry, got a broken diff last time. Use this patch.

Perhaps the method "nautilus_file_get_symbolic_link_target_uri" [1]
from file nautilus-file.c/h should be removed.
It was only used in the method "nautilus_file_get_activation_uri". My
patch deactivates the call to [1] in order to fix this bug/problem.

Have fun.

I agree with this change. In CVS soon.

 2003-01-20  Alexander Larsson  <alexl@redhat.com>
 
         * libnautilus-private/nautilus-file.c:
         Revert the symlink activation change. For later discussion.

So is this now fixed?

The change was reverted by popular request. We haven't decided on a
final behaviour.

This version of Nautilus (now 2.2.1 on Redhat 9) still has problems
with symbolic links.

First let me point out that earlier posts make the mistake of using
shell behavior with respect to symlinks as a baseline.  This isn't
helpful, since the shells writers/user have had the same
physical-vs-logical path debate for ages, and the behavior is settable
in bash, for example, as a user preference (set -P option).

Mostly the user preference refers exclusively to the meaning of "..".
Personally I think that both logical and physical should be tracked,
with a choice in apps such as nautilus, but this would just confuse
newbies.  (But I like the idea of two up buttons being available in
such cases)

On the other hand, I am actually having a problem.  What I wish to do
is create a reference on the desktop to a directory in the
filesystem..  Copying them is out of the question.  No mechanism is
available on the root menu - or if Create New Launcher is it, I don't
see how.  So, I used the "ln -s" command to create a symlink in
.gnome-desktop.  This works fine, appearing immediately on the desktop
and being clickable UNLESS the path I link to contains a symlink. If
it does, then -sometimes- clicking on it doesn't work.  Unfortunately
I can't reproduce this reliably, so nevermind.

Puzzled by this, I attempted to browse to /pod/games directly.  Most
of the time this worked, although clicking on "pod" from a view of
root immediately produced /fs/d1/pod in the Location: bar.  But one
time, it got caught in some kind of loop, spawned about 20 additional
views, and then returned control.  Odd.  I can't duplicate this
either, though.

But the difficult with making a symlink from .gnome-desktop to start
with remains, so does anyone think these might be worth adding?:

1) The ability to make a link to a resource on the desktop by dragging
from a nautilus window without it trying to make a copy. Well,
actually dragging would allowing making links between nautilus windows
to, just putting one on the desktop could be done with a action in a
pulldown on the it to link to.
2) A way to create a link on the desktop from the root menu by
entering the path as text would be nice.

Chiming in with a +1 to revert back to not jumping all over the place.
This is horribly confusing. 

I would also like to point out that Windows "links"/shortcuts are not
the same thing as *NIX symlinks since this seems to be the argument
for the jumping behavior. Windows shortcuts are the equivelant of
.desktop files (i.e. they are normal files stored with a .lnk
extension that contain info similar to .desktop files). Windows
recently (maybe around win2000) got real symlinks (well.. kinda) for
NTFS. They are called JUNCTIONS and I have never seen a windows app
follow a junction. This would defeat the purpose of having a true
filesystem linking mechanism in the first place.

I would suggest making a distinction between real filesystem links and
shortcuts as they are two separate concepts that require different
behaviors. Shortcuts (or .desktop files) should hop, symlinks should not.

*** Bug 128882 has been marked as a duplicate of this bug. ***

Here is comment from bug 128882. I closed it and marked as duplicate.

If I have symlink to directory, and I enter into this directory through
symlink, and use "Up" button, then I'm not back in the symlink's parent
directory but in parent of real directory.
The "Location" shows the real directory, not the
symlinked one. This also makes confusion. As in my example:
you are in "/home/ala" and go to "sample". After that nautilus shows in
"Location": /home/olaf/test, but the user expects /home/ala/sample.

Below is example:

Directory:
/home/olaf/test

symlink:
/home/ala/sample -> /home/olaf/test

I start in /home
I go to "ala"
I am in /home/ala
I go to sample
And nautilus shows that I am: /home/olaf/test
If I push "Up" button I go to /home/olaf.

I want nautilus to show /home/ala/sample 
and if push "Up" to go to /home/ala

Users get crazy when they see
/mnt/sda5/vol7/... and they expected to be in /home/projects/.....

*** Bug 115639 has been marked as a duplicate of this bug. ***

2004-01-11  Alexander Larsson <alexl@redhat.com>

  * libnautilus-private/nautilus-file.c
(nautilus_file_get_activation_uri): 
  Don't expand symlinks when following them.

As this has been corrected, can someone please mark this bug as
resolved/fixed?

Closing.