সহায়তা খুঁজুন

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

আরও জানুন

How to prevent version 13.0 from following symlinks

  • 12 উত্তরসমূহ
  • 7 এই সমস্যাটি আছে
  • 1 দেখুন
  • শেষ জবাব দ্বারা selkovjr

more options

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?

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?

txema.gonz দ্বারা পরিমিত

All Replies (12)

more options

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.

txema.gonz দ্বারা পরিমিত

more options

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.

more options

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

more options

Do you think we should open a ticket somewhere?

(I guess there is one)

more options

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.

more options

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.

more options

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.
more options

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.

selkovjr দ্বারা পরিমিত

more options

Continues in 15.0.

more options

And in 16.0 beta.

more options

Now in 16.0 beta 6

more options

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.