I might have filed this under the wrong component, I apologize in advance, I don't know enough about mozilla innards. Although I have filed it under Linux, it probably applies to all Unix-like os's. Onto the problem: When I download a file and specify an application to open it with in the dialog, mozilla immediately resolves the symbolic link in the name if any. e.g., if I ask that a file be opened with /a/b/c and /a/b/c is really a symbolic link to /a/b/d then the link is resolved and the file is opened with /a/b/d. This is weird because /a/b/c might actually depend on being invoked as /a/b/c to know what to do. For instance, I have a bunch of applications that all point to the same script that decides what to do by looking at $0. But I'm unable to use them within mozilla.

Oh, yikes. This is a problem with nsIFile.... We need to fix this.

OK. Now that I think about it... Washington, how exactly are you specifying the application? Step-by-step details including every single char you type and where you type it could be relevant here.... (it looks like we're calling normalize() somewhere where perhaps we should not be...).

Ok, I'm using a realplayer example here. Although this would not be a problem with realplayer (i.e., the resolved symlink still handles realaudio), presumably you can all play along at home and see the symptoms: First I cleared out my preferences for audio/x-pn-realaudio Now on my linux system: 132 emsworth:cpc/lib> ls -l `which realplay` lrwxrwxrwx 1 root root 10 Jul 11 17:42 /usr/bin/X11/realplay -> realplayer* Also: 136 emsworth:cpc/lib> ls -l /usr/bin/X11 lrwxrwxrwx 1 root root 12 Oct 16 16:49 /usr/bin/X11 -> ../X11R6/bin/ Meaning that /usr/bin/X11/realplay is really pointing at /usr/X11R6/bin/realplayer via 2 levels of indirection so realplay is a link. now, I click on a realuadio link, I get the dialog box: You have chosen to download a file of type: audio/x-pn-realaudio from http://play.rbn.com/ What should mozilla do with this file? I check Open using an application. Click on the Choose button In the file picker, I navigate (using the up one directory button to go all the way to /, then navigating down) to /usr/bin/X11, choose realplay, click Ok. Filepicker goes away and already the dialog is showing: Open using /usr/X11R6/bin/realplayer So I don't know at what point it got resolved, but it did. Now I click Ok etc, and it gets set in my preferences as /usr/X11R6/bin/realplayer. Thanks

Washington, thanks. Sounds like the problem is the filepicker...

We need to not call normalize() in the filepicker unless we absolutely have to... even then, it would be nice to normalize out the ".." without resolving symlinks...

washington, per #3, if this is working for you, can you "RESOLVED/WORKSFORME"?

This is not resolved. The "resolved" in comment 3 is referring to the symlink, not this bug. This bug is very much real and will happen any time the filepicker calls normalize(). Too bad we have no way to normalize without following symlinks. Perhaps we should?

A dumb question, if I may. Why normalize any executable path? All you need to do is try it. It either works or it doesn't. What am I missing?

When someone opens the filepicker to directory /home/foo and types "../bar" in the textfield and hits enter we want to show them as being in /home/bar, not /home/foo/../bar. So we have to normalize paths that are typed in. The rest is just a matter of codepath reduction; since selecting a file puts the name in the textbox we just key off the textbox value for everything. This is a problem in its own right, of course. Oh, and the filepicker has no knowledge of executables (yet). It just knows you want a file(name) and tries to provide one as reasonably as it can...

Well, if a user enters "../bar" I don't see why mozilla wouldn't display exactly what the user typed. The principle of minimum surprise. A temporary workaround might be to split the path into the basename and dirname components, normalize just the dirname, and reassemble the new path. As I think about it, I don't think mozilla (actually mozilla-bin) should mess with executable paths at all.

> Well, if a user enters "../bar" I don't see why mozilla wouldn't display > exactly what the user typed. Because _no_ other app does this. Try this in your shell -- put your current dir into the prompt, go somewhere, type "cd .." and see what your current dir is listed as. > A temporary workaround might be to split the path into the basename and > dirname components, normalize just the dirname, and reassemble the new > path. Wouldn't necessarily help this bug -- the dirname can contain symlinks. Feel free to suggest a better UI and approach if you have a constructive idea.

> Because _no_ other app does this. Try this in your shell -- put your > current dir into the prompt, go somewhere, type "cd .." and see what your > current dir is listed as. True, but you're using the prior knowledge of "cd .." to condition your expectation of the result. I don't object to this, it's the right thing. It would be nice if mozilla was context sensitive. Note that "cd .." isn't as well-defined as you might want. Try this. ln -s /tmp/bar ~/foo mkdir /tmp/bar bash -c 'set -P; cd ~/foo; pwd; cd .. ; pwd; echo` bash -c 'set +P; cd ~/foo; pwd; cd .. ; pwd; echo` Where you wind up depends on how you view the world. > Wouldn't necessarily help this bug -- the dirname can contain symlinks. Do you have an example of how this would fail? I'm probably missing something again. > Feel free to suggest a better UI and approach if you have a constructive > idea. I must admit I don't like the file picker dialog because it is a) too small and hard to use and b) opens in the last directory it was in which is never the one I want. Navigating to where I want to put something is a real pain. Ignoring that, using context is certainly a good idea. If you're manipulating a directory (like clicking the dirup button) then you use one set of rules. You could normalize after each change. You might want to use either a logical or physical view as in the above example. Windows does something like this. My WinXP generally offers to load from or store an object into "My Whatever". That's certainly a logical view. There's no reason to assume all Linux users want a physical view. If you're looking for a place to store a file then that's really a directory view with a new name appended. If you're looking for a helper app then you should offer the option of accepting the user's input as typed (a relative path) or normalizing it into an absolute path. For example, if I want to associate a given mime type with "gunzip" I probably want mozilla to accept what I typed because it's unlikely I know where gunzip actually is. Bottom line, defer normalization until absolutely necessary. Expose an option for logical or physical views in a directory context. Expose an option whether to normalize paths to executables (which would solve this specific issue).

> Note that "cd .." isn't as well-defined as you might want. Yeah, life is hard like that. > Do you have an example of how this would fail? Not sure yet. It _does_ avoid the issue of programs that look at $0.... Unfortunately, the dialog does not have all the context it would need (eg it has no idea it's looking for a helper app). But yes, we could be smarter (which is why this bug is still open).

> Not sure yet. It _does_ avoid the issue of programs that look at > $0.... Maybe that's enough for this bug? The grand scheme for world conquest can wait a while.

I won't get to this in the foreseeable future. If someone could help out, that would be great.

I've seen something similar to this in the Phoenix browser. Since Phoenix is based on Mozilla, I think this is the same bug. In Phoenix, I can specify a directory (folder) where I want to save all files. I specify /net/zeus/users/rgriswol/tmp, but Phoenix turns this into /a/zeus.eecs.wsu.edu/vol/vol0/users/rgriswol/tmp. This causes major problems, since my home directory is shared between Linux and Solaris, and /net/zeus/users is not the same between the two OSes: Linux: /net/zeus/users -> /.automount/zeus/vol/vol0/users Solaris: /net/zeus/users -> /a/zeus.eecs.wsu.edu/vol/vol0/users As long as I do not have .. in the path, it should remain as I entered it.

that phoenix issue is entirely separate, please file a new bug.

I should stop pretending I will ever have time to get to this.

note that a fix for bug 56662 would likely fix this bug as well (if done "correctly", contrary to what the patch that's currently there does)

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

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

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

As a workaround, can bug 278179 be implemented instead?

note that mozilla allows manually entering a path name. I don't know whether tbird/ffox do.

No in both cases.

For trouble with programs that looks into $0 (my problem is with gvim, a link to vim), couldn't you remove symlink resolution only for files. As the problem linked to the normalization is only when using .. after symlinks to directories, this can be easily done, and should not create troubles.

> this can be easily done oh? how?

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

As an addendum to this bug, I would like to add that the gtk file selection dialog under linux is woefully inadequate for selecting the program to open a file with. From a usability point of view, here are the steps required: 1. Click on link, opens "Open With." dialog. 2. Click on drop down labelled "Open with:" and select "Other...", GTK file selection dialog opens, defaulting $HOME. 3. Double-Click "Filesystem" in left column. 4. Double-Click "usr" in right. 5. Double-Click "bin" in right. This operation takes approximate 30 seconds (one-one-thousand, two-one-thousand style counting) on my computer, 1 gig of ram, 2.4ghz, fedora core 3. 6. Scroll down extremely long list of files to select appropriate application. A 'better' arrangement would ideally be. 1. Click on link. 2. Click on "Open with:" and select "Other..." 3a. Type the name of the application (autocomplete the same way 'bash' does). 3b. Optionally click "select from filesystem" and have that default to $HOME, with several other likely locations ($HOME/Desktop, /usr/bin/, /usr/local/bin/, etc) listed instead of the current dialog (locations available are Home, Desktop and Filesystem).

Am I misunderstanding this, or are bug 291426 and bug 247792 claiming this is fixed? Or could those just be a manifestation of bug 208739?

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

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

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

Please disregard my previous comment.

Why do you even use the filepicker at all for this? Why not just let the user type the command in that they want to run, including any dash options, etc. ? A long time ago, Mozilla didn't have this bug... it simply let you type in a program such as "vi" or "gimp" and it automatically used your PATH environment variable to find the program. This behavior was correct and simple. I vote you just go back to that behavior (at least for Unix).

I see two things here: 1) It looks like there should be either an option on the normalize() call or a second function: normalize_dirs which does NOT resolve the terminal symlink where [ -s $filename ] && [ ! -d $filename/. ] (those semantics may still break for OS-X, where [I believe] an application can be in the form of a directory -- in that case, a slightly different check may be needed). _________________ The other is that: I second the motion that there should be an ability to just type in 'gvim' at the "helper app" chooser and have mozilla resolve the name by quietly following the PATH variable. (and not resolving the terminal symlink to 'vim' which is a non-gui mode of the editor) PERHAPS the reason why this was changed is that there is an issue where $PATH includes '.', and '$progname' resolves to ./$progname which might break if you subsequently start the browser from a different directory. In THAT SPECIFIC INSTANCE, it _might_ be worthwhile to normalize the directory path (but still preserve any terminal symlink name)

The contents of the user's $PATH variable is irrelvent. If they have '.' in their path, then the user has a security problem that it isn't within the Mozilla projects domain to fix. I heartily agree with the idea that 'typing in the name of the command to use' should be reintroduced, at least as an option. Especially if it allows for being able to do things like 'xterm -e "less %1"', at the moment, doing something along those lines requires writing a shell script.

Removes an invokation of realpath(3), as the man-page for this function explicitly declares its use as inherently buggy. This is manifested, though for reasons unrelated to what the manpage listed, in the Firefox bug which causes zombies and hang-ups, due to invoking incorrect helper applications.

To clarify the above, I'm royally teed off that Firefox won't let me select either gvim nor gmplayer for viewing (rather than downloading) media files or unusual or improperly MIME-typed text files. Careful observation shows that, in both cases, this bug causes the following chain of events to occur: 1. Browser issues a call to realpath() which, perhaps inadvertently, resolves symbolic links. 2. The software is invoked, perhaps via fork() somewhere else in the code. 3. Software, which has a *console* command form, expects to find a controlling terminal, which doesn't exist. The software abnormally terminates. 4. Firefox, meanwhile, waits for normal completion of the software, which is now dead. The zombie thus hangs around taking up a process slot, while Firefox just waits *forever*, requiring a killall -9 firefox to get rid of it. Whether this gets rid of the zombie or not depends on what process is actually run, and less often, the phase of the moon. By simply "short-circuiting" the realpath() library call, this whole situation is avoided. I can now use symlinked executables as helpers without problems. I am requesting the attached patch be code reviewed for inclusion. Thanks!!

You have to pick someone to review the patch, otherwise nobody gets notified that there's a review pending.

I would really, really like this patch to be included in subsequent releases of Firefox. I'm not sure if I need to also check the approval1.8.1.2 flag or not, though. Thanks!

Comment on attachment 256130 [details] [diff] [review] Performs path normalization, but not filename normalization. This will fix it if the symlink is appname -> otherappname, but not if the symlink is /usr/bin/firefox -> /usr/lib/firefox-1.5/firefox Which I think is unexpected behavior. If all we want to do is remove .. path components, we should do that and stop using realpath() altogether. Whatever we do, we absolutely need to document what the correct behavior is and have some tests. The correct behavior of Normalize may depend on the nsILocalFile.followLinks setting.

This is bogus -- please tell me *one* situation where this even makes a difference. > Which I think is unexpected behavior. If all we want to do is remove .. path > components, we should do that and stop using realpath() altogether. This behavior is idempotent though, and therefore IS expected behavior (indeed, neither the user nor the system will ever know the difference). The symlink that is used to launch the program with could not possibly care any less about how that symlink was accessed. > Whatever we do, we absolutely need to document what the correct behavior is and > have some tests. The correct behavior of Normalize may depend on the > nsILocalFile.followLinks setting. "may"? Either it does or it does not. And it certainly didn't depend on it before. AND, there is no user-settable option to follow symlinks or not in my copy of Firefox. This bug is already five years old. Nobody has done anything about it. It's caused me substantial data loss. ANYTHING is better than nothing at this point. I strongly urge you to reconsider your denial of the patch.

> ANYTHING is better than nothing at this point. Quite on the contrary. If the bug is old, then some weeks or months more don't make much difference. (Are you saying that we should accept bad fixes in favour of good ones just because a bug is old?)

"Bad" is a pretty subjective evaluation. Please list in what ways the patch is "bad"? This question has been asked a few times before, but not *one* person responded with a *single* case. On the contrary, I can see numerous reasons why my patch does satisfy this bug: From Comment 5: > We need to not call normalize() in the filepicker unless we absolutely have > to... even then, it would be nice to normalize out the ".." without resolving > symlinks... OK, I haven't touched the filepicker, but, how does the file picker know when and when not to invoke Normalize()? It shouldn't ever have to know, frankly. From Comment 10: > A temporary workaround might be to split the path into the basename and > dirname components, normalize just the dirname, and reassemble the new > path. This is precisely what my patch does. From Comment 11: > Wouldn't necessarily help this bug -- the dirname can contain symlinks. > Feel free to suggest a better UI and approach if you have a constructive idea. A non-issue: kc5tja@aldeberan:~$ ln -s /usr/bin BLORT kc5tja@aldeberan:~$ ls -la BLORT lrwxrwxrwx 1 kc5tja users 9 2007-02-22 19:15 BLORT -> /usr/bin/ kc5tja@aldeberan:~$ cd BLORT kc5tja@aldeberan:~/BLORT$ echo "<-- notice the unresolved symlink." Even tab completion isn't affected: kc5tja@aldeberan:~$ BLORT/gvim gvim gvimdiff kc5tja@aldeberan:~$ BLORT/gvim Yes, I'm sure you can set Bash to behave differently (this is demonstrated in a previous comment), but the point is clear: Bash doesn't care. Linux *certainly* doesn't care. I know BSD doesn't either. Solaris is a BSD derivative, as is Darwin. I cannot think of any exceptions. From Comment 14: > > Not sure yet. It _does_ avoid the issue of programs that look at > > $0.... > > Maybe that's enough for this bug? The grand scheme for world conquest > can wait a while. I would like to also assert this view. This bug is directly relavent to launching of applications that check $0. That's it. Nothing more, nothing less. In all the comments provided thus far, there is absolutely zero evidence to suggest even one failure case. From comment #27, in response to #26: > > this can be easily done > oh? how? My patch demonstrates how. Of all the people who contributed to the bug's comments, why am I the only one to have contributed any code at all? Are you aware that all I did was take what was already discussed as *solutions* to this bug, and realized it? This bug fix isn't even my own genius. I'm just someone who lost a fair bit of data in my work because of this bug, and I took the time out of my schedule to offer a fix. That IS how open source is supposed to work, yeah? I'm not even asking for recognition. I just want the bug fixed. Or, at least, "fixed enough." I don't mean to sound ****, but I feel rather trampled by the rejection of a simple solution to what is otherwise such a trivial problem. I feel like my effort is distinctly and singularly wasted, and that this issue will never be resolved. Ever. Is the purpose of normalization *solely* to resolve excess /s and ..s from pathname components? If so, I'll write something to do that if need be (but, I'm not going to lie to you, it will not produce any different results, except to not resolve ANY symlinks at all!). But don't just tell me "it won't work," and then offer zero evidence to support your claim. Benjamin's response is not satisfactory, again, because it lacks any evidence to support his claim. Christian: the bug is old, but it seems to keep cropping up over and over again. It's like that itch that you just can't get to to scratch. It needs to be resolved. I don't care when, I just care that it *IS* fixed sometime before the next release of Firefox.

This is broken as hell. I use sox to play sounds, and it expects to be called as /usr/bin/play, except this fine piece of software follows the link and calls /usr/bin/sox which then goes "what the **** do you want me to do?" since it expects arguments in that case. So sounds don't work. Nice. And you had to add extra code to screw this up, you couldn't just use what the user specifies. REAL NICE! And you people can't seem to fix it.

Dear developers; in addition to comment #46, another problem with de-referencing the symlink is with programs that include version numbers. E.g. start with gnumeric-1.8.3, there is a symlink "/usr/bin/gnumeric" pointing to it. Yesterday, I ran a system update which happened to update gnumeric, so I now have... waltdnes@d530 ~ $ ll -og /usr/bin/gnumeric lrwxrwxrwx 1 14 Mar 28 21:58 /usr/bin/gnumeric -> gnumeric-1.8.4 When I tried opening a .CSV file from a website today, Firefox whined that the helper application (gnumeric-1.8.3) didn't exist. A lot of apps have version numbers, often allowing you to have different versions installed, and running, simultaneously. The default symlink is updated by the installer to point to the latest version. And a *SANE* program launcher, when told to /usr/bin/gnumeric will, indeed, attempt launch /usr/bin/gnumeric. But not Firefox. No, it has to try to launch the non-existant /usr/bin/gnumeric-1.8.3, and fails. To quote comment #46 > Nice. And you had to add extra code to screw this up, you > couldn't just use what the user specifies. REAL NICE! Please stop trying to act like Windows or Mac programmers; stop trying to second-guess me. Any time I update gnumeric (xls and csv files) or abiword (doc files) I have to go through the rigamarole of re-setting the helper-file association. Please let the user type in a program name (e.g. /usr/bin/gnumeric) and use that name. I'm a big boy. If I F*** up, it's my fault. if you can't make it a default, at the very least please give me an "expert option" in about:config or user.js or elswhere, to allow me to over-ride this braindead code.

Here's a quick-n-dirty work-around... With the help of "grep -r", I found references to to gnumeric-1.8.4 in file mimeTypes.rdf in my user account directory. I... 1) shut down Firefox 2) created a backup of mimeTypes.rdf 3) in mimeTypes.rdf manually edited all occurences of "/usr/bin/gnumeric-1.8.4" and "/usr/bin/gnumeric-1.8.3" (why was it still around?) down to "/usr/bin/gnumeric". 4) restarted Firefox The app associated with CSV files is now simply "gnumeric". Nothing has blown up. My only complaint now is that I had to hack my way around the bug.