X
Tap here to go to the mobile version of the site.
Your Firefox is out of date and may contain a security risk! Upgrade Firefox

Support Forum

How to prevent version 13.0 from following symlinks

Posted

We are developing a test framework in the the test directory.

Some other folders contain a soft link (ln -s) to file test.html inside the test directory.

In previous versions when dragging the link to the browser ,it wasn't resolved. In that way we could scope test.html to the files in that module.

Now, the file protocol always points to the test dir.

Is there any way to prevent firefox from following the symlinks any longer?

Modified by txema.gonz

Additional System Details

Installed Plug-ins

Firebug sqlite manager

Application

  • User Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:13.0) Gecko/20100101 Firefox/13.0

More Information

The addres bar says:
file:///home/user/work/project/test/test.html
instead of
file:///home/user/work/project/src/kernel/tests/test.html

Helpful Reply

A possible workaround is to install an apache server and create a symbolic link inside the root dir (/var/www in my case) to the project dir.

Then you can switch to the http protocol.

This solutiion works partially but enforces to all the developers to install apache.

Modified by txema.gonz

plasticstare 0 solutions 1 answers

Helpful Reply

The worst thing about this is the fact that any query string appended to the original url is obliterated when the symlink is followed, which even further renders testing scenarios unusable.

Running apache and addressing the test page does workaround the issue, but this is unnecessary for other browsers.

I am running FF 13 on OSX.

jscher2000
  • Top 10 Contributor
2368 solutions 20966 answers

Possibly related (unsolved) thread: cannot open local shtml file -- symlink resolves to page and display open/save/cancel dialog.

Question owner

Do you think we should open a ticket somewhere?

(I guess there is one)

jscher2000
  • Top 10 Contributor
2368 solutions 20966 answers

I often miss bugs in the bug tracking system Buzilla but you could take a look and see whether you find it. If you file a new bug and it is recognized as a duplicated, someone will add a note to your bug so you can find the earlier one.

Question owner

Seems that nobody has posted something similar there.

I've been taking a look at this page: Document Loading - From Load Start to Finding a Handler amongst others.

I think the error might be in the necko package (on netwerk/protocol/file directory). Before disturbing the developers I want to:

  1. Write a page with a file protocol link and check out whether this keeps failing. If it doesn't fail here, then the problem should be in the address bar.
  2. Debug nsFileProtocolHandler.cpp

When I get done with all of these I'll create the ticket and put here the link to it.

Thanks to all.

Question owner

Tested => Firefox has the same behaviour with the the links, so:

  • it's not a problem with the address bar.
  • Our next stop is in the file handler protocol.
selkovjr 0 solutions 8 answers

Same behaviour on Linux as on OSX. Even the old links pulled from history are replaced with link targets. And, this behaviour has been carried over to 14.0.

Modified by selkovjr

selkovjr 0 solutions 8 answers

Continues in 15.0.

selkovjr 0 solutions 8 answers

And in 16.0 beta.

selkovjr 0 solutions 8 answers

Now in 16.0 beta 6

selkovjr 0 solutions 8 answers

Same in 17.0 and in today's Nightly.

Is there a plan for fixing it? It is a major regression -- I cannot open a file in Firefox.