242970 - Bug 241708 has broken Mail&News when mail directry on different drive from one for profile directry. (Server Settings/Local directory was changed to \\.\D:\pop3.server.name after 2004-04-29 build)

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Account Configuration, defect)

Description

[WADA:World Anti-bad-Duping Agency]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040505
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040505

Spin off from Bug 242579 Comment #11

On 2004-04-29 trunk build(Win32),
local directory of Account/Server Settings was changed to \\.\D:\pop3.server.name
even though user_pref("mail.server.serverN.directory","D:\\pop3.server.name");
is properly set in prefs.js.
If drive is C:, local directory setting was not changed.

If Server Setting is canceled, no change is saved in prefs.js.
But if user does not aware of change and press OK, this is written to prefs.js.

This problem started to occur on 2004-04-29 trunk nightly build(Win32,ZIP) and
still occurs on latest nightly.
No problem on 4/28,4/27,4/24,4/21 trunk nightly builds(Win32,ZIP build).

This bug seems to be affected by change of Bug 241708.
> 2004-04-29 01:16 mozilla/ xpcom/ io/ nsLocalFileWin.cpp 	1.118
> Bug 241708 nsIFile support for unc paths is almost entirely broken
> Handle local computer (\\.) allowing enumeration of local drives,
> and access to local computer from local drives via |parent|.
> The parent of local computer is null.

Reproducible: Always
Steps to Reproduce:

Comment 1

[David :Bienvenu]

we don't use the .directory pref anymore - we use the .directory-rel pref,
though we should upgrade the .directory pref if we encounter it. But changing
the .directory pref after the .directory-rel pref has been set should have no
effect. Perhaps there's still some code looking at the .directory pref.

Comment 2

[WADA:World Anti-bad-Duping Agency]

Sorry, I forgot directory-rel.

2004-04-29 build changed both directry & directory-rel.

[D: drive] 

(Before restart)
user_pref("mail.server.server4.directory", "D:\\test.pop3.server");
user_pref("mail.server.server4.directory-rel",
"[ProfD]../../../../../../../../D:/test.pop3.server");

(Local directory didplay) \\.\D:\test.pop3.server

(After Server settings save)
user_pref("mail.server.server4.directory", "\\\\.\\D:\\test.pop3.server");
user_pref("mail.server.server4.directory-rel",
"[ProfD]../../../../../../../..//./D:/test.pop3.server");

[C: drive]

(Before restart)
user_pref("mail.server.server11.directory", "C:\\test2.pop3.server");
user_pref("mail.server.server11.directory-rel",
"[ProfD]../../../../../../../test2.pop3.server");

(Local directory didplay) C:\test2.pop3.server (Unchaged)

(After Server settings save)
.directry & .directory-rel were not changed if C: drive

Comment 3

[WADA:World Anti-bad-Duping Agency]

dir "\\.\D:\test.pop3.server" returned next result.
> Drive \\.\D: Volume Label EDICUBE-D (<= This is label of my local D: )
>  Volume Serial ACF3-18EC
>  \\.\D:\test.pop3.server
>  (file list of directry)
This is apparantly valid format of local resource at least in command line
interface on MS Windows.

Comment 4

[timeless]

Yes it's valid, I don't invent things like this :).

The real problem is that: MailNews should not use a "relative" path across
volumes. The idea of relative paths is that they're supposed to make profiles
portable. However, in the case of volumes, this means that if your profile
directory moves up one level, a path to something on another volume no longer works.

I will try to work on this over a weekend. And will make sure this is fixed by alpha

Comment 5

[Mirco Romanato]

I also experienced this problem.
A partial workaround was to create a fake folder in C:\ pointing to the volume
where the mail are (C and H are NTFS volumes)

C:\fake ==> H:\
C:\fake\Mail\Local Folder == H:\Mail\Local Folder

Comment 6

[David :Bienvenu]

I believe the fix for  bug 241708 broke this.

Comment 7

[timeless]

Attachment: Failing to set a relative descriptor is not an error case

Comment 8

[David :Bienvenu]

I've run with this patch, and the one in bug 241708, and while it may help going
forward, for when users change the directory, it did nothing for my existing
problem - this makes it sound like we need to convert the directory-rel prefs
out there that no longer work...somehow.  I'll see if that actually fixes the
problem.

Comment 9

[WADA:World Anti-bad-Duping Agency]

Same problem occured on local directry(mail directry) on C: drive, when I
defined Mozilla's profile directry on D: drive.
Problem always occurs when mail directry is defined on different drive from one
for profile.

Workarounds :
(A) Move mail directry(local directry) to the drive on which profile is defined.
(B) Move profile directry to the drive on which mail directry(local directry) is
defined.

Comment 10

[timeless]

Comment on attachment 148192 [details] [diff] [review]
Failing to set a relative descriptor is not an error case

mozilla/mailnews/base/util/nsMsgUtils.cpp	1.93

Comment 11

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #10)
> (From update of attachment 148192 [details] [diff] [review])
> mozilla/mailnews/base/util/nsMsgUtils.cpp	1.93

Your patch was checked-in on 5/11 but my Comment #9 is test result with
2004-05-17 trunk build, and problem still occurs.

I think real problem is ;
When mail directry(Local directry) is defined on different drive from one for
other profile directry,
"[ProfD]../../../../../../../../D:/test.pop3.server" 
 in .directry.rel is converted to "\\\\.\\D:\\test.pop3.server" by your fix for
Bug 241708, then new .directry-rel becomes
"[ProfD]../../../../../../../..//./D:/test.pop3.server".
This causes this bug, then Bug 242579 started to occur.
This is the word "broken" in Comment #6 by David Bienvenu, I believe.

Higher path by "../" does not include drive letter?
Please note that "Drive Letter part" is legal file path part in URI
representation, for example,
file://localhost/D|/directry/subdirectry-1/subdirectry-2/filename.ext,
although "..\" in MS DOS command does not include drive letter.
I believe relative path concept should base on URI format instead of MS DOS
command format.

Comment 12

[WADA:World Anti-bad-Duping Agency]

I've read Bug 241708 Comment #10 and Bug 241708 Comment #11.
David, why the patch which caused problem is still not backed-out? 

Comment 13

[WADA:World Anti-bad-Duping Agency]

This bug was fixed by David's patch of Bug 241708 Comment #14, which is included
in   2004-02-21-08 trunk build(Win 32), although this patch is included in 1.8a1
release build(2004-05-20 build).
Thanks for your patch, David. 

Comment 14

[WADA:World Anti-bad-Duping Agency]

Correction (sorry for spam)
His patch is not included in 1.8a1 release build.
It is included in trunk builds after 2004-05-21 trunk build only.

Comment 15

[Mike Cowperthwaite]

*** Bug 243742 has been marked as a duplicate of this bug. ***