1512812 - Handling of mapped network drives in Windows changed in TB 60: Drive letter now resolved to UNC path for account directory prefs affecting profile

Status: NEW

(Thunderbird :: OS Integration, defect)

Description

[joschu]

Attachment: BUGfullInfo.txt

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0

Steps to reproduce:

Since Thunderbird 60.x, currently 60.3.3, profile paths are resolved incorrectly on network drives mapped with a drive letter.
Problem A) Thunderbird stores and uses "\\server\share$\folder\SUBPATHTOPROFILE" instead of "X:\SUBPATHTOPROFILE". This happens when new profiles are created OR when such paths are migrated from 59.x to 60.x.
Problem B) Thunderbird does not properly create the relative paths inside the profile anymore.

Until 59.x, this worked on an network drive letter:
user_pref("mail.server.server1.directory", "X:\\SUBPATHTOPROFILE\\ImapMail\\test.test.test");
user_pref("mail.server.server1.directory-rel", "[ProfD]ImapMail/test.test.test");

With 60.x, only this works with a real relative path:
user_pref("mail.server.server1.directory", "\\\\server\\home$\\yourhome\\TB\\Profile\\ImapMail\\test.test.test");
user_pref("mail.server.server1.directory-rel", "[ProfD]ImapMail/test.test.test");

Using the PROPER absolute path with a network drive letter, we need a non-relative path construct:
user_pref("mail.server.server1.directory", "\\\\server\\home$\\yourhome\\TB\\Profile\\ImapMail\\test.test.test");
user_pref("mail.server.server1.directory-rel", "[ProfD]../../../../../X:/SUBPATHTOPROFILE/ImapMail/test.test.test");

Steps to reproduce:
Make a share "share$" on "server", with a personal subfolder "yourhome".
Connect your homedrive "H:\" to "\\server\home$\yourhome".
Start Thunderbird with "-P" to manually create a new Profile.
Point your Thunderbird Profile to be in "H:\TB\Profile".
Manually configure a fake offline IMAP account on server "test.test.test".



Actual results:

prefs.js contains at least the following misconfiguration:
user_pref("mail.root.imap", "\\\\server\\home$\\yourhome\\TB\\Profile\\ImapMail");
user_pref("mail.root.imap-rel", "[ProfD]ImapMail");
user_pref("mail.root.none", "\\\\server\\home$\\yourhome\\TB\\Profile\\Mail");
user_pref("mail.root.none-rel", "[ProfD]Mail");
user_pref("mail.server.server1.directory", "\\\\server\\home$\\yourhome\\TB\\Profile\\ImapMail\\test.test.test");
user_pref("mail.server.server1.directory-rel", "[ProfD]ImapMail/test.test.test");
user_pref("mail.server.server2.directory", "\\\\server\\home$\\yourhome\\TB\\Profile\\Mail\\Local Folders");
user_pref("mail.server.server2.directory-rel", "[ProfD]Mail/Local Folders");


Expected results:

It should be (and used to be with 59.x):
user_pref("mail.root.imap", "H:\\TB\\Profile\\ImapMail");
user_pref("mail.root.imap-rel", "[ProfD]ImapMail");
user_pref("mail.root.none", "H:\\TB\\Profile\\Mail");
user_pref("mail.root.none-rel", "[ProfD]Mail");
user_pref("mail.server.server1.directory", "H:\\TB\\Profile\\ImapMail\\test.test.test");
user_pref("mail.server.server1.directory-rel", "[ProfD]ImapMail/test.test.test");
user_pref("mail.server.server2.directory", "H:\\TB\\Profile\\Mail\\Local Folders");
user_pref("mail.server.server2.directory-rel", "[ProfD]Mail/Local Folders");

See attached BUGfullInfo.txt for the whole thing and Examples.

Comment 1

[joschu]

Oh, SORRY, I have an important error in the text and in the attached BUGfullInfo.txt:

FALSE:
Using the PROPER absolute path with a network drive letter, we need a non-relative path construct:
user_pref("mail.server.server1.directory", "\\\\server\\home$\\yourhome\\TB\\Profile\\ImapMail\\test.test.test");
user_pref("mail.server.server1.directory-rel", "[ProfD]../../../../../X:/SUBPATHTOPROFILE/ImapMail/test.test.test");

CORRECT:
Using the PROPER absolute path with a network drive letter, we need a non-relative path construct:
user_pref("mail.server.server1.directory", "X:\\SUBPATHTOPROFILE\\ImapMail\\test.test.test");
user_pref("mail.server.server1.directory-rel", "[ProfD]../../../../../X:/SUBPATHTOPROFILE/ImapMail/test.test.test");

Comment 2

[Wayne Mery (:wsmwk)]

Does Firefox have the same issue?

Comment 3

[joschu]

(In reply to Wayne Mery (:wsmwk) from comment #2)
> Does Firefox have the same issue?

I don't use FireFox 6x.x, but since my 59.x FireFox ESR 32bit prefs.js doesn't contain a single *-rel path pref or any other path pref that resembles the mentioned Thunderbird prefs, I don't think the bug wouldn't even matter as much.
I could imagine that the bug is there, too, but without depending mechanics that lead to these symptoms.

Comment 4

[Jorg K (CEST = GMT+2)]

Your report is full of confusion as to which versions you are using. The current TB version is 60, the previous major version was 52. You write about 59 and even 69(!!).

That said, TB really only supports profiles on real physical drives, anything else is playing with fire. Take a look at bug 760937 or bug 1427192. Basically we run the path through Normalize() and that's where the trouble starts, see bug 760937 comment #43.

Comment 5

[joschu]

(In reply to Jorg K (GMT+1) from comment #4)
> Your report is full of confusion as to which versions you are using. The
> current TB version is 60, the previous major version was 52. You write about
> 59 and even 69(!!).
> 
> That said, TB really only supports profiles on real physical drives,
> anything else is playing with fire. Take a look at bug 760937 or bug
> 1427192. Basically we run the path through Normalize() and that's where the
> trouble starts, see bug 760937 comment #43.

Hello Jorg K
thanks for your fast reply.
I'm am really sorry about the inconsistencies in my report.
Yes, I meant 52.x instead of 59.x and yes, I have one typo saying 69.x instead 59.x.
(I was still shellshocked after fixing a live 30-user-environment the day after the upgrade, fiddling around until I found the cause and trying to make a reproducable guide to provoke the error from scratch.)
PLEASE ADVISE: Should I mark this Bugreport as INVALID and post another one that is shorter and corrected?
I don't want to cause trouble here, just help!

I administer Thunderbird on Windows user homedrives that are connected with a driveletter almost since it exists.
My oldest stored Mails from the company state "rv:1.6" and "Gecko/20040113".
I can safely say that Thunderbird NEVER had a problem with this in 13 years.
It is very common that users in a Windows infrastructure have their homedrives mounted as a driveletter and applications use their data there.
This has huge strategic advantages when it comes to failovers or migrations, because you can switch the source under the driveletter, no matter if you want to go from local to server or server to server.
The method of mapping a network drive to a drive letter resembles a linux mount point, NOT a symlink.
So all in all I think calling this "playing with fire" is really very wrong!
(Just imagine Thunderbird would discard a linux mount and address the server with an alternative path instead.)

Fortunately Thunderbird 60.x doesn't convert mapped networkdrives to UNC-paths all the time, just during migration or creation of profiles.
After fixing the absolute path prefs to the mapped locations and deleting the relative companions (to have them so strangely recreated), it works.

Comment 6

[Wayne Mery (:wsmwk)]

> TB really only supports profiles on real physical drives

Although it is certainly true with regard to cloud services, I've never heard this with regard to network drives - and presumably this would also be true of Firefox. Is this documented somewhere?

Comment 7

[Jorg K (CEST = GMT+2)]

Looks like I never posted the following comment which I typed after comment #4:
And as Wayne hinted in comment #2: We use Mozilla platform code for profile management, so you'd have to reproduce this using Firefox to stand a chance to get some attention.

That said, something has changed between TB 52 and TB 60, and TB is more affected than FF. I'd have to find some time to see what changed. I guess it's all about how those names get "normalised" in this code:
https://searchfox.org/mozilla-central/rev/dc3585e58b427c3a8a7c01712fe54ebe118a3ce2/xpcom/io/nsLocalFileWin.cpp#1321
This file has seen a few changes recently:
https://hg.mozilla.org/mozilla-central/log/tip/xpcom/io/nsLocalFileWin.cpp
Masatoshi-san, are aware of any changes to Normalize()? I've been looking very hard and can't find any:
https://hg.mozilla.org/mozilla-central/annotate/c2593a3058afdfeaac5c990e18794ee8257afe99/xpcom/io/nsLocalFileWin.cpp?ignorews=1#l1434

I'd also need to see where mapped network drives are converted to UNC-paths in the code.

Looking at comment #0 TB 52 stored this
user_pref("mail.root.imap", "H:\\TB\\Profile\\ImapMail");
whereas TB 60 stores this:
user_pref("mail.root.imap", "\\\\server\\home$\\yourhome\\TB\\Profile\\ImapMail");
The relative path still seems to be the same, right?
user_pref("mail.root.imap-rel", "[ProfD]ImapMail");

So clearly, the path has been normalised, most likely here:
https://searchfox.org/comm-central/rev/6ff0a001e73986bb4a273a1aa7db5fb2752ec017/mailnews/base/util/nsMsgIncomingServer.cpp#484

So reporter, which corrections did you make to restore things to working order? If I read attachment 9030092 [details] correctly, you removed the *-rel preferences? So did "H:\\TB\\Profile\\ImapMail" get changed to "\\\\server\\home$\\yourhome\\TB\\Profile\\ImapMail" as well, or only "during migration or creation". What's migration? You mean upgrade?

Comment 8

[joschu]

(In reply to Jorg K (GMT+1) from comment #7)
> Looks like I never posted the following comment which I typed after comment
> #4:
> And as Wayne hinted in comment #2: We use Mozilla platform code for profile
> management, so you'd have to reproduce this using Firefox to stand a chance
> to get some attention.

I will try to reproduce something as soon as possible with Firefox ESR 60.3.0, but I'll need to setup a VM first and I think there will be nothing similar to the involved Thunderbird prefs. Let's see...
 
> [...]
> So reporter, which corrections did you make to restore things to working
> order? If I read attachment 9030092 [details] correctly, you removed the
> *-rel preferences? So did "H:\\TB\\Profile\\ImapMail" get changed to
> "\\\\server\\home$\\yourhome\\TB\\Profile\\ImapMail" as well, or only
> "during migration or creation". What's migration? You mean upgrade?

The Thunderbird 52.x prefs.js files contained before:
absolute: H:\\TB\\Profile\\Imapmail
relative: [ProfD]Imapmail

After UPGRADING the Thunderbird programfiles from 52.x to 60.3.2 and starting, they were converted to:
absolute: \\\\server\\share\\path\\TB\\Profile\\Imapmail
relative: [ProfD]Imapmail

After that, the Sent folder in all mailaccounts looked strange and the external signature file was unaccassible.

Because I need "serverless" networkpaths on driveletters, I corrected...
absolute: H:\\TB\\Profile\\Imapmail
...and deleted the relative path to have it automatically be recalculated to...
relative: [ProfD]../../../../H:/TB/Profile/Imapmail

All involved prefs I came accross so far:
mail.identity.idX.sig_file , mail.identity.idX.sig_file-rel
mail.root.imap , mail.root.imap-rel
mail.root.none , mail.root.none-rel
mail.root.pop3 , mail.root.pop3-rel
mail.server.serverX.directory , mail.server.server1.directory-rel

Comment 9

[Jorg K (CEST = GMT+2)]

Thanks, this is clear now. So the upgrade touched those prefs :-(

Comment 10

[joschu]

(In reply to Jorg K (GMT+1) from comment #9)
> Thanks, this is clear now. So the upgrade touched those prefs :-(

I just tested the upgrade from FireFox 52.9 ESR 32bit to 60.3. ESR 64bit and 32bit.
I configured the only paths I could think of, resulting in:
  user_pref("browser.download.dir", "H:\\FF\\down");
  user_pref("browser.download.lastDir", "H:\\FF\\down");
These prefs remained unchanged after the upgrades.
If you can think of other tests, I can try those...

Comment 11

[Jorg K (CEST = GMT+2)]

(In reply to Jorg K (GMT+1) from comment #7)
> And as Wayne hinted in comment #2: We use Mozilla platform code for profile
> management, so you'd have to reproduce this using Firefox to stand a chance
> to get some attention.
Looks like this comment was mostly wrong, sorry. Sure, profile management is done by Mozilla platform code used in FF and TB. But TB creates stuff within the profile with its own preferences. So looks like something has changed.

Comment 12

[Jorg K (CEST = GMT+2)]

OK, I set up a network drive, moved the profile onto it like so:

[Profile12]
Name=UNC
IsRelative=0
Path=X:\Profiles\4bcj3l5n.UNC
Default=1

and created an IMAP account in TB 52. Result:
mail.server.server1.directory      X:\Profiles\4bcj3l5n.UNC\ImapMail\mail.your-server.de
mail.server.server1.directory-rel  [ProfD]ImapMail/mail.your-server.de
mail.server.server2.directory      X:\Profiles\4bcj3l5n.UNC\Mail\Local Folders
mail.server.server2.directory-rel  [ProfD]Mail/Local Folders

Started TB 60 on the profile. No change. So how did you manage to get this changed during the upgrade??

Created a new IMAP account, and there we have it:
mail.server.server3.directory      \\SAPO3\temp\TB\Profiles\4bcj3l5n.UNC\ImapMail\mail.your-server-1.de
mail.server.server3.directory-rel  [ProfD]ImapMail/mail.your-server-1.de

OK, so the behaviour has changed, but I can't don't get any problem during upgrade, well, I didn't do an upgrade, I've just run TB 60 in the profile.

Next I removed the server3.directory-rel and restarted. It came back as before. For 1 and 2 it came back crazy as you had described: [ProfD]../../../../../../X:/Profiles/4bcj3l5n.UNC/Mail/Local Folders

Next test: Back into TB 52 and manual update to TB 60. Looking at the prefs, no change!!

So while the behaviour has certainly changed when creating new accounts, I can't see that upgrade did anything. I also don't see why updating the program would visit all the accounts and mess with the prefs.

So can you retrace your steps to see what cause the change during upgrade? I will check on our side what caused the change on account creation.

Comment 13

[Jorg K (CEST = GMT+2)]

Alice, can you help us to find the regression here. The setup is a little complicated :-(

First you start TB 52 and create a new profile, call it UNC. Don't add any account, just exit after the first start.

Then visit C:\Users\NNNNN\AppData\Roaming\Thunderbird. Edit profiles .ini. For the profile you've just created, change the entry to:
[Profile..] <== leave the number here
Name=UNC
IsRelative=0
Path=X:\Profiles\xyzt.UNC <== this will vary
Default=1

Next, create C:\temp. For temp, in Windows, use Properties, Sharing, Advanced Sharing. Change permissions to Full Control for Everyone.

Next create a folder TB in temp.

Next in Windows Explorer, click on "This PC", expand the ribbon, and click "Map network drive". Create drive X: for \\yourmachine\temp\TB. "yourmachine" is the name of your machine. This will only work if temp is shared.

Next cut/paste the xyzt.UNC folder from C:\Users\NNNNN\AppData\Roaming\Thunderbird to X:\ or C:\temp\TB. They are the same.

Now start TB 52 again. You should be able to select the UNC profile. That's the setup.

Now here the STR:
Simply create an account. It can be a mail account, which is slow to set up, or create a Feed Account:
Tools > Account Settings, Account Actions, Add Feed account. Now check the "directory" preferences. They should contain
  X:\Profiles\xyzt.UNC
Delete the feed account again.
Repeat with the next version. I need to know which version starts to create
  \\yourmachine\temp\TB\profiles
instead of using X: as above.

Thanks in advance!!

Comment 14

[joschu]

(In reply to Jorg K (GMT+1) from comment #12)
> [...]
> Started TB 60 on the profile. No change. So how did you manage to get this
> changed during the upgrade??
> 
The problem in this stage is that some stuff is partly broken.
Starting TB 60 on a 52 profile, you should see the "Sent" folder without symbol.
A german "Postausgang" localization would be gone. You would see "Sent".
If you had an external signature file on the account it would be gone.
Then you would need to fix all that by deleting the *-rel prefs.

> [...]
> OK, so the behaviour has changed, but I can't don't get any problem during
> upgrade, well, I didn't do an upgrade, I've just run TB 60 in the profile.
I always upgrade TB by replacing its program files with a newer version.
I never ever ran the end-user-upgrade procedure - just to get the files.

> [...]
> Next test: Back into TB 52 and manual update to TB 60. Looking at the prefs,
> no change!!
But it is partly broken as described above until the *-rel prefs are regenerated, right?

> So while the behaviour has certainly changed when creating new accounts, I
> can't see that upgrade did anything. I also don't see why updating the
> program would visit all the accounts and mess with the prefs.
> 
> So can you retrace your steps to see what cause the change during upgrade? I
> will check on our side what caused the change on account creation.

I just replaced the whole profile of a productive user with snapshot data from TB 52.
Same thing as you observed:
The path prefs stay as they are, signature file unaccessible, Sent folder looks naked.
I deleted the *-rel prefs and everything works with the strange regenerated rel-paths.

Comment 15

[Jorg K (CEST = GMT+2)]

(In reply to joschu from comment #14)
> > Next test: Back into TB 52 and manual update to TB 60. Looking at the prefs,
> > no change!!
> But it is partly broken as described above until the *-rel prefs are
> regenerated, right?
No, not on the English version I'm using. The Sent folder kept its icon and everything is fine.

I've now changed the Sent folder in the account settings and now mail.server.server1.directory has changed to 
\\SAPO3\temp\TB\Profiles\4bcj3l5n.UNC\ImapMail\mail.your-server.de. The -rel pref is still
[ProfD]ImapMail/mail.your-server.de
I didn't regenerate anything, it's all still working.

Maybe the localised version is different.

Comment 16

[Jorg K (CEST = GMT+2)]

I've tried a German version of TB 60. Works fine on the TB 52 profile, the X: is maintained, Sent is now called Gesendet. Sure, when you re-configure the account or create a new one, you get the UNC paths.

Comment 17

[joschu]

(In reply to Jorg K (GMT+1) from comment #16)
> I've tried a German version of TB 60. Works fine on the TB 52 profile, the
> X: is maintained, Sent is now called Gesendet. Sure, when you re-configure
> the account or create a new one, you get the UNC paths.

I'm getting old. It's "Gesendet", that's what I meant all the time, yes.
Strange that you can't reproduce it.
In production, I can reproduce the effect again and again by going back to 52 profile data.
But there's also existing data in the IMAP account that is not so easy to simulate.

Could you point to a signature file within your profile in TB 52?
It should be unaccessible in TB 60 and the path should look funny in the options UI.
Something like...
\\server\share\folder\pathtoprofile\ImapMail\mailserver\TestSig.txt
...instead of...
X:\pathtoprofile\ImapMail\mailserver\TestSig.txt .
Before and after you fix the path in the UI to X:\
you will see that same transition of the relative path to [ProfD]../../../../blabla

It's great that you put so much serious effort into this, THANK YOU.
I need to go to sleep now, it's 01:00 here.

Comment 18

[Alice0775 White]

Regression window:
https://hg.mozilla.org/comm-central/pushloghtml?fromchange=6ccad3aa817af34d04fd8585ba0ce642f0b9193b&tochange=2983f04886b61661fc69d2eb5262084f902e0486
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8f80d594c08d5c7a112e5d4b9eb44ffca717eb7b&tochange=0b5603017c25e943ba3ab97cb46d88adf1e6a3e4

Suspect:  2983f04886b6	Jorg K — Bug 1375680 - Port bug 1367813 to TB/SM - rename ReadUserPrefs() to ReadUserPrefsFromFile(). rs=bustage-fix

Comment 19

[Jorg K (CEST = GMT+2)]

Thanks Alice. Would it be possible to narrow it down a bit more? The M-C range is very long. https://hg.mozilla.org/comm-central/rev/2983f04886b6 is only about profile migration, I don't think this code is run when creating an account. It's more likely that bug 1367813 changed the behaviour of the system.

Comment 20

[Alice0775 White]

(In reply to Jorg K (GMT+1) from comment #19)
> Thanks Alice. Would it be possible to narrow it down a bit more? The M-C
> range is very long. https://hg.mozilla.org/comm-central/rev/2983f04886b6 is
> only about profile migration, I don't think this code is run when creating
> an account. It's more likely that bug 1367813 changed the behaviour of the
> system.

Unfortunately, Thunderbird old tindebox build and task-cluster artifact had already been expired. 


Other scenario on Firefox. (but, I think same root cause)

STR
Create a shared folder and assign drive letter to it.
Create an empty folder in it
Create new profile from profile manager and choose the folder(drive-letter:\path to profile)

Launch Firefox with the profile
Open Profile folder from about:support on Firefox.
Window explorer opens the profile folder, and then click address bar of explorer:

Actual Results:
Last Good build:  drive-letter:\path to profile
First bad build:  \\server name\path to profile.

Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=0cec50535e2c38b00e8ed3a1a29be4d4935757be&tochange=c1983642406a1ad7768d5d2363e521c11b4f1b2a

Regressed by: Bug 1369670

Comment 21

[Jorg K (CEST = GMT+2)]

Brilliant Alice!!! I filed bug 1513172 for FF.

Maybe for TB we can fix the issue by compiling with MOZ_CONTENT_SANDBOX not defined:
https://hg.mozilla.org/mozilla-central/rev/c1983642406a#l2.32

Or I can back out the M-C change on TB's branch on m-esr60. Another backout, sigh :-(

Comment 22

[Jorg K (CEST = GMT+2)]

OK, pointed a signature at X:\Profiles\4bcj3l5n.UNC\sig.txt. That's stored into mail.identity.id1.sig_file. mail.identity.id1.sig_file-rel is [ProfD]sig.txt.

Opened the profile with the German TB 60. New message, signature is there and working. Pref hasn't changed. OK, going into the account setup, the X: is now resolved to: \\SAPO3\temp\TB\Profiles\4bcj3l5n.UNC\sig.txt

I went OK, created a new message, all still working. The -rel pref hasn't changed.

So in summary:
Drive letters are converted to UNC path when you go near them, like when creating new accounts, changing folders in an existing account, like selecting a different folder for deleted items, editing the signature.
That's easily reproducible and we can see the change in the Mozilla platform code onto which Thunderbird and Firefox are built. Whilst losing the drive letter is unfortunate and we'll see how we can restore the previous state, I cannot see any visible problems caused by the change of behaviour. I have connected my test profile to a *real* IMAP account with real data in it. Sent/Gesendet remains fully functional, as does the signature.

So what's different about your data? Are there any add-ons that might beaver around those preferences? Anything else you can think of. Since we already so much time on this, how about you download the old 52.9.1 form here
http://ftp.mozilla.org/pub/thunderbird/releases/52.9.1/win32/

and try the whole thing on a new profile, make sure you disable automatic updates.

I'm the release manager of Thunderbird, so I need to know how bad the problem it. I could imagine that you're not the only one using drive letters, but I haven't heard any complaints other then yours. TB 60 has been around for a while and the change was made at version 56 of Mozilla.

Comment 23

[joschu]

(In reply to Jorg K (GMT+1) from comment #22)
> [...]
> and try the whole thing on a new profile, make sure you disable automatic
> updates.
> 
> I'm the release manager of Thunderbird, so I need to know how bad the
> problem it. I could imagine that you're not the only one using drive
> letters, but I haven't heard any complaints other then yours. TB 60 has been
> around for a while and the change was made at version 56 of Mozilla.

This is what I manages to try today.

Before trying on a new profile, I try to get a view on whats actually broken and why.
I detected trouble with the msf files in the IMAP account data.
They come a long way and originally work with TB 52, the Sent folder looks good.
Picked up by TB 60 they partly look broken, Archives, Drafts and Sent.
After deleting the -rel prefs, TB 60 repairs something.
In the UI everything loks fine again, but there ary new bypass-msf files next to the untouched originals.
Archives.msf -> Archives-1.msf
Drafts.msf -> Drafts-1.msf
Sent.msf -> Sent-1.msf
I remember that you can delete msf files to have the index repaired, right?
So I went back to the original profile state, opened TB 52, everything looked fine.
I deleted the msf files, opened TB 52 again, it looked broken.
SO NOTE: There may be a sleeping problem with the old msf-files and the old config, just not triggered yet.

Next noteworthy experiment:
I went back to the old profile state checked once with TB 52.
Then I deleted the -rel prefs out of prefs.js. Just running the fix in advance.
After picking up the profile with TB 60, everything went fine!
No bypass msf files, healthy look.
No UNC-path conversions as absolute paths!
Of course the relative paths are "[ProfD]../../../bla".
I spotted an "Invalidprefs.js" anyways.

I have to skip the "new profile" test for now, sorry.

Comment 24

[Jorg K (CEST = GMT+2)]

Yes, you can delete MSF files and they will be rebuilt. As I said above, my -rel path are all [ProfD]ImapMail/mail.your-server.de.

The problem in general is not as severe as first assumed. Yes, it's a little annoying since you lose the paths via the drive letter. However, the UNC paths aren't the end of the world: \\server\directory\etc. OK, you have the server hard coded, but the directory is already the name of a network share and you can move that around as you deem fit as long as you maintain the name, no?

Comment 25

[joschu]

(In reply to Jorg K (GMT+1) from comment #24)
> The problem in general is not as severe as first assumed. Yes, it's a little
> annoying since you lose the paths via the drive letter. However, the UNC
> paths aren't the end of the world: \\server\directory\etc. OK, you have the
> server hard coded, but the directory is already the name of a network share
> and you can move that around as you deem fit as long as you maintain the
> name, no?

Sorry, but converting a serverless path into a serverpath just like that is bad practice.
A mapped network driveletter is the logical root of the file system objects it contains.
It's NOT a symlink, not a junction and is not to be handled as such.
Everybody that wants the UNC for a driveletter needs to check the drivetype, make queries and reconstruct the path - it's not directory traversal and not supposed to be.
When you mount an UNC path on a letter, you DON'T WANT traversal below that point.
From the approx. 70 products I prepare for use in my university environment in the locked down open access windows computer pools , I remember only very few that do that.
Those are cross-platform and I can understand that one flirts with UNC paths because they resemble the posix root paths a little better.
I had plenty of data migrations of user data before and it is much more convenient if you can switch servers under a drive letter with persistent configurations without hacking.
The other 30 people environment that made me start this report will have their H: drives switched from serverA to serverB in case of problems or maintenance.
I have added the following to everyone's user.js and I wish I wouldn't have to:
user_pref("mail.server.server1.directory-rel", "");
user_pref("mail.server.server2.directory-rel", "");
user_pref("mail.server.server3.directory-rel", "");
user_pref("mail.server.server4.directory-rel", "");
user_pref("mail.server.server5.directory-rel", "");
user_pref("mail.server.server6.directory-rel", "");
user_pref("mail.server.server7.directory-rel", "");
user_pref("mail.server.server8.directory-rel", "");
user_pref("mail.server.server9.directory-rel", "");
user_pref("mail.identity.id1.sig_file-rel", "");
user_pref("mail.identity.id2.sig_file-rel", "");
user_pref("mail.identity.id3.sig_file-rel", "");
user_pref("mail.identity.id4.sig_file-rel", "");
user_pref("mail.identity.id5.sig_file-rel", "");
user_pref("mail.identity.id6.sig_file-rel", "");
user_pref("mail.identity.id7.sig_file-rel", "");
user_pref("mail.identity.id8.sig_file-rel", "");
user_pref("mail.identity.id9.sig_file-rel", "");
I know that's ugly, but I don't know how to properly delete a pref.
If it turns out the bug won't be fixed, I might hack the prefs.js with another logonscript instead.
That would be just another fix one has to keep in mind, sadly this time for an otherwise very reliable fantastic piece of software :)
OK, enough pleading, I rest my case now.
Good night and thanks again!

Comment 26

[Jorg K (CEST = GMT+2)]

OK, OK, I'll see what I can do. But first we need to see what the Mozilla platform people tell us in bug 1513172.

If you already lock down the prefs in user.js, why don't you hard-code the TB 52 values for the directory and the directory-rel as well as the signature files?

Comment 27

[joschu]

(In reply to Jorg K (GMT+1) from comment #26)
> OK, OK, I'll see what I can do. But first we need to see what the Mozilla
> platform people tell us in bug 1513172.
> 
> If you already lock down the prefs in user.js, why don't you hard-code the
> TB 52 values for the directory and the directory-rel as well as the
> signature files?

Hi Jorg
for locking, I use general.config.filename based lockPrefs with just a handful of global behavioral prefs.
By planting the user.js I don't lock or hardcode anything, it just makes TB start with soft corrections.
(I want to keep this fix away from TBs programfiles at the moment, otherwise I guess I could add it there.)

I do it this way because I need to trigger a proper recalculation of the rel-paths every time TB starts.
TB sees the empty string value, falls back to my absolute H: network path pref (that I don't need to hardcode), calculates its new strange [ProfD]../../H:/bla/bla relative path, then works with that.
In case the bug gets fixed or the my servers under H: change, this will work dynamically without touching every users' prefs.js.

I wish I knew how to DELETE a pref instead of setting an illegal empty string to provoke this.
Also, if FF and TB had a global option NOT to generate and/or use relative path prefs in the first place, it would help.
I googled it but couldn't find anything!?

Comment 28

[Matt]

I recall seeing release notes somewhere that said the mozilla platform no longer supported mapped drive letters. So this bug is probably invalid.

Comment 29

[Jorg K (CEST = GMT+2)]

Not invalid, see bug 1513172.

Comment 30

[Wayne Mery (:wsmwk)]

(In reply to Jorg K (CEST = GMT+2) from comment #26)

OK, OK, I'll see what I can do. But first we need to see what the Mozilla
platform people tell us in bug 1513172.

was fixed via Bug 1695556 - Windows sandbox does not allow accessing files in MOZ_DEVELOPER_REPO_DIR

Magnus, Anything left to do here?

Comment 31

[Magnus Melin [:mkmelin]]

Someone on windows should check. Create a share and map it to a letter, put the profile there and see what paths we use.