1385755 - symlink user.js treat as 0 bytes on Windows

Status: RESOLVED FIXED

(Core :: Preferences: Backend, defect)

Description

[kudwafter114514]

Attachment: Captued log by Procmon

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:54.0) Gecko/20100101 Firefox/54.0
Build ID: 20170628075643

Steps to reproduce:

1. ``mklink user.js user.txt`` in profile directory.
2. write some setting to user.txt.
3. (Re)Start Firefox.

Build ID 	20170730100307
User Agent 	Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0


Actual results:

Firefox dones not read user.js.

Started from Firefox 45(Build ID 	20160303134406).


Expected results:

Firefox read setting from user.js.

Until Firefox 44(Build ID 	20160123151951) was reading the link target.

Comment 1

[Benjamin Smedberg]

Code in question: https://dxr.mozilla.org/mozilla-central/source/modules/libpref/Preferences.cpp#1266

Regression caused by bug 1219310. I wonder if we could ask the *stream* for its size, rather than the file. Otherwise we'll need to add symlink resolution to the nsIFile which is a PITA.

Comment 2

[Nathan Froyd [:froydnj]]

(In reply to Benjamin Smedberg [:bsmedberg] from comment #1)
> Code in question:
> https://dxr.mozilla.org/mozilla-central/source/modules/libpref/Preferences.
> cpp#1266
> 
> Regression caused by bug 1219310. I wonder if we could ask the *stream* for
> its size, rather than the file. Otherwise we'll need to add symlink
> resolution to the nsIFile which is a PITA.

We were asking the stream for its size before bug 1219310, so I think we can certainly do that. :)  I guess we could just back out the first part of the bug?  Do we have any sort of policy on symlinks in the profile directory?

Comment 3

[Benjamin Smedberg]

No policy. People do lots of weird shit though.

Comment 4

[Masatoshi Kimura [:emk]]

No longer reproduced on 67. I guess this is fixed by bug 1363482:
https://searchfox.org/mozilla-central/diff/bfafcc2b0611c13bda2c07afebd14ac1d2f8f418/modules/libpref/Preferences.cpp#1278