![Firefox logo](https://assets-prod.sumo.prod.webservices.mozgcp.net/media/uploads/products/2020-04-14-08-36-13-8dda6f.png)
updatet firefox broke link direktory
I have some web project in ~/www/Release folder. It can work with 2 application server. One is placed in xx.xx.xx.105 IP, another in xx.xx.xx.6 IP. I make 2 folders 105 and 6, and link all files from ~/www/Release to them (ln -s Release/* ./), except settings.xml. Then I try to open (ctrl+o) ~/www/6/index.html - firefox open's ~/www/Release/index.html and settings.xml from the Release dir, not from ~/www/6 dir. Google Chrome and previous FireFox works fine.
Изабрано решење
I confirmed that when you load a file:///some/symlink url in firefox 13 you are immediately redirected to the symlink's target. Unfortunately I believe (I'm not 100% sure I'm right about the guilty code) this change was introduced as part of the fix for bug 670514, which is a security bug that's still restricted (http://www.mozilla.org/security/announce/2012/mfsa2012-37.html links to this bug). As I cannot see that bug I cannot tell you if the behavior you now see is entirely intentional or not, but I'm afraid it probably is.
I think you could work around this by using hardlinks instead of symlinks. My personal preference would be to use a version control system so you can track changes to both branches, but that may be a more invasive change than you're comfortable with.
Прочитајте овај одговор са објашњењем 👍 0Сви одговори (2)
Одабрано решење
I confirmed that when you load a file:///some/symlink url in firefox 13 you are immediately redirected to the symlink's target. Unfortunately I believe (I'm not 100% sure I'm right about the guilty code) this change was introduced as part of the fix for bug 670514, which is a security bug that's still restricted (http://www.mozilla.org/security/announce/2012/mfsa2012-37.html links to this bug). As I cannot see that bug I cannot tell you if the behavior you now see is entirely intentional or not, but I'm afraid it probably is.
I think you could work around this by using hardlinks instead of symlinks. My personal preference would be to use a version control system so you can track changes to both branches, but that may be a more invasive change than you're comfortable with.
Using hard links is partially solved the problem. The disadvantage of lack of supplies possibilities to create hard links to directories. I hope that this is a bug and not the correct behavior of the browser.