Closed Bug 1268842 Opened 6 years ago Closed 6 years ago

Starting with Firefox 46.0, my profile is not recognized anymore under Mac OS 10.11 if it has symlinks in it (e.g. places.sqlite is a symlink to a file)

Categories

(Toolkit :: Startup and Profile System, defect)

46 Branch
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: macosx12345, Unassigned)

Details

(Keywords: regressionwindow-wanted)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20160407164938

Steps to reproduce:

In the profile (~/Library/Application\ Support/Firefox/Profiles/xxx.default for instance), move some files (bookmarkbackups, key3.db, places.sqlite, signons.sqlite) to another directory and replace them by symbolic links to the new files.
E.g. key3.db is a symbolic link to ../../../../../../some/dir/key3.db .


Actual results:

Under Mac OS 10.11.4:
When launching Firefox 46.0, the history is empty and the previous session can't be restored. With Firefox 45.0.2, the history was not empty. If there are no symbolic links in the profile, the history displayed by Firefox 46.0 is not empty.


Expected results:

The history should have not been empty.
Component: Untriaged → Startup and Profile System
Product: Firefox → Toolkit
If you create a symlink to the entire profile (/Firefox/Profiles/xxx.default <-> some/dir/xxx.default) instead of only for a few files of the profile, does it work normally?
Flags: needinfo?(macosx12345)
(In reply to Loic from comment #1)

Yes, it does work normally.
I tried with Firefox 46 and symlink to files key3.db and logins.json, the passwords are still present in the password manager after restarting the browser.
(on Win 7 64 bits)
(In reply to Loic from comment #4)

For me (on Mac OS 10.11.4) too: the passwords are still present in Prefences/Security/Saved logins. But the history is empty.
Ok, I'll try only with places.sqlite.
I moved places.sqlite, WFM.
I tried only with places.sqlite: suffices to reproduce the problem (under Mac OS 10.11.4).
It could be an issue only with Mac OSX.

Cornel, could you find someone from QA who can try to reproduce on OSX, please.

STR: create a symlink for places.sqlite and restart Firefox to check the history.
Flags: needinfo?(macosx12345) → needinfo?(cornel.ionce)
Issue still present with Firefox 46.0.1.
I'm able to reproduce this issue with latest Nightly 49.0a1, but also with 45.0.2RC - with a symlink for places.sqlite, I'm unable to restore the previous session.
Tested under 2 different Mac OS X 10.10.5 machines.
Flags: needinfo?(cornel.ionce)
I dont have a Mac OSX machine to test, so someone from QA with a Mac needs to run Mozregression to find a regression range.

The best thing to do is creating a new profile, populate the history by visiting a few websites then create a symlink for places.sqlite. After that, Mozregresion can be launched with this new profile and the command 
--profile=path-to-profile --profile-persistence=reuse.
Flags: needinfo?(alexandra.lucinet)
I did some detective work today and I learned that this symlink issue appears to be fixed in Firefox 48.

Since it is not fixed in Firefox 47 alpha, grab this "nightly" build and try it out:

http://archive.mozilla.org/pub/firefox/nightly/2016/03/2016-03-29-03-02-46-mozilla-central/

This is a build of 48.0a1 from March and a closely related symlink problem is fixed for me. I pinpointed the date the problem originated to October 31, 2015. I don't have the exact date of when it was fixed.

Please let me know if it works for you so we can close this ticket as well.
Also reproducible with the build via comment 13 (48.0a1 from 2016-03-29) and even with 37.0a1 from 2014-12-01. Let me know if I can help more!
Flags: needinfo?(alexandra.lucinet)
(In reply to jgotts from comment #13)
> I did some detective work today and I learned that this symlink issue
> appears to be fixed in Firefox 48.
> 
> Since it is not fixed in Firefox 47 alpha, grab this "nightly" build and try
> it out:
> 
> http://archive.mozilla.org/pub/firefox/nightly/2016/03/2016-03-29-03-02-46-
> mozilla-central/
> 
> This is a build of 48.0a1 from March and a closely related symlink problem
> is fixed for me. I pinpointed the date the problem originated to October 31,
> 2015. I don't have the exact date of when it was fixed.
> 
> Please let me know if it works for you so we can close this ticket as well.

 With the above build of 48.0a1, the problem is solved indeed (for me under Mac OS 10.11.4).
I'm glad I was able to help. Mozilla developer Loic was an invaluable aid for us.
(In reply to jgotts from comment #16)
> I'm glad I was able to help. Mozilla developer Loic was an invaluable aid
> for us.

Thank you, but I dont work for Mozilla. ;)
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:49.0) Gecko/20100101 Firefox/49.0

I have tested on latest FF release (46.0.1) and latest Nightly ( 20160508030214) and could not reproduce it. I have moved some files (bookmarkbackups, key3.db, places.sqlite) in another folder and created symbolic links to them. I have visited a few websites in different tabs and I've closed the browser from the "Exit Nightly" button located in the main menu. After reopening Firefox, the history was available and I was able to restore the previous session.

I've also tested this on Mac OS X 10.8, 10.10, 10.11, using Firefox 45.0.2, 46.0, 46.0.1 along with Nightly 49.0a1.

Is this still reproducible on your end? If yes, can you please retest this using latest FF release and latest Nightly build (https://nightly.mozilla.org/) and report back the results? When doing this, please use a new clean Firefox profile, maybe even safe mode, to eliminate custom settings as a possible cause (https://goo.gl/PNe90E).
Flags: needinfo?(macosx12345)
Considering the fact that I cannot reproduce this and the fact that the reporter did not answered to my request until now, I will mark this as Resolved-Worksforme.

If anyone can still reproduce it, feel free to reopen the issue and provide more information.
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Flags: needinfo?(macosx12345)
Resolution: --- → WORKSFORME
(In reply to Emil Pasca [:emilpasca] from comment #19)
> Considering the fact that I cannot reproduce this and the fact that the
> reporter did not answered to my request until now, I will mark this as
> Resolved-Worksforme.
> 
> If anyone can still reproduce it, feel free to reopen the issue and provide
> more information.

As indicated in comment 15, a build of 48.0a1 solved the issue, and since Firefox 48.0 was officially released, I think the issue can be considered as solved for the general public.
You need to log in before you can comment on or make changes to this bug.