452468 - Migration wizard JavaScript error: , line 0: uncaught exception: [Exception... "Component returned failure code: 0x80520006 (NS_ERROR_FILE_TARGET_DOES_NOT_EXIST)

Status: RESOLVED WORKSFORME

(SeaMonkey :: General, defect)

Description

[Martin Mokrejs]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.16) Gecko/20080722 SeaMonkey/1.1.11
Build Identifier: Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.2pre) Gecko/2008082711 SeaMonkey/2.0a1pre

During the import wizard I have received:

JavaScript error: , line 0: uncaught exception: [Exception... "Component
returned failure code: 0x80520006 (NS_ERROR_FILE_TARGET_DOES_NOT_EXIST)
[nsISuiteProfileMigrator.migrate]"  nsresult: "0x80520006
(NS_ERROR_FILE_TARGET_DOES_NOT_EXIST)"  location: "JS frame ::
chrome://communicator/content/migration/migration.js :: anonymous :: line 360"
data: no]

I have no more details. I suspect it happened while converting "Mail Folders" from 1.1.11 profile, but who knows?

Reproducible: Always

Steps to Reproduce:
1.
2.
3.



Build platform
target
i686-pc-linux-gnu

Build tools
Compiler        Version         Compiler flags
gcc     gcc version 4.3.1 (Gentoo 4.3.1-r1 p1.1)        -Wall -W -Wno-unused
-Wpointer-arith -Wcast-align -W -Wno-long-long -pedantic -fno-strict-aliasing
-pthread -pipe
c++     gcc version 4.3.1 (Gentoo 4.3.1-r1 p1.1)        -fno-rtti
-fno-exceptions -Wall -Wconversion -Wpointer-arith -Woverloaded-virtual -Wsynth
-Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-long-long
-pedantic -fno-strict-aliasing -fshort-wchar -pthread -pipe

Configure arguments
--disable-optimize '--enable-debug=-g3\ -O0\ -ggdb' --enable-debug-modules=all
--enable-debugger-info-modules --enable-detect-webshell-leaks --enable-svg
--enable-svg-renderer-libart --enable-image-decoders=all --with-qtdir=/usr/qt/3
--enable-application=suite --disable-freetype2 --enable-jprof
--enable-default-toolkit=cairo-gtk2 --enable-xft --disable-gssapi

Comment 1

[Andrew Schultz]

Do you still have the old 1.1.x profile that you tried to migrate?  I don't know how to diagnose this beyond starting with that profile and removing parts from it until migration works.

Comment 2

[Martin Mokrejs]

Yes, I still do use the old profile, that was just an attempt to see if I can use the upcoming version or not yet. So, you mean to delete some files from the profile? Please give me an example. and, before I start that, could some debug output be added to comm-central TRUNK?

Comment 3

[Andrew Schultz]

> So, you mean to delete some files from the profile?

Yes.  Backup the profile first certainly.  :)

Looking at the code in more detail, it looks like it's getting stuck on
http://mxr.mozilla.org/comm-central/source/suite/profile/migration/src/nsSeamonkeyProfileMigrator.cpp#130
(or line 131)

So, it's trying to copy hostperm.1 and cookperm.txt.  The actual failure is happening in xpcom guts that are actually doing the copy, but I can't imagine it would fail with NS_ERROR_FILE_TARGET_DOES_NOT_EXIST unless the directory it was copying to (the new profile directory) didn't exist.  Not sure how that would happen.

Deleting hostperm.1 and/or cookperm.txt would make the error go away, but it'd probably just fail on the next thing it tried to copy over, so I guess you can hold off on that for now.

Comment 4

[Robert Kaiser]

Is this failure an exception or does it happen in common cases? If the latter is not the case, I'm tempted to blocking- this for the first Alpha.

Comment 5

[Robert Kaiser]

Not blocking as I can't reproduce on my Linux notebook, so it doesn't seem to be a general problem, probably only a specific case.

Comment 6

[Martin Mokrejs]

I cannot even try to reproduce it due to inability to compile sources with debug flags (bug #455468).

Comment 7

[Frank Wein [:mcsmurf]]

How does this bug here depend on Bug 455468? JavaScript errors also occur without debug flags.

Comment 8

[lenochod]

(In reply to comment #0)
> Configure arguments
> --disable-optimize '--enable-debug=-g3\ -O0\ -ggdb' --enable-debug-modules=all
> --enable-debugger-info-modules --enable-detect-webshell-leaks --enable-svg
> --enable-svg-renderer-libart --enable-image-decoders=all --with-qtdir=/usr/qt/3
> --enable-application=suite --disable-freetype2 --enable-jprof
> --enable-default-toolkit=cairo-gtk2 --enable-xft --disable-gssapi

Reporter cannot compile with Configure arguments (--enable-debug=-g3\ -O0\ -ggdb) for this bug, see quotation.

Comment 9

[Frank Wein [:mcsmurf]]

I very much doubt that the only way he can compile is with this flags. And even if it is, it's not a problem for everyone, so it does not really depend on that bug.

Comment 10

[Martin Mokrejs]

I very much doubt I could compile in the debug code by another way. At least, I was never told about another and the docs do not exist. If a trunk debug build binary would have been provided of the ftp site by the project I would gladly use it.

Comment 11

[Frank Wein [:mcsmurf]]

What's wrong with --enable-debug? And as said, JavaScript errors also work in a normal build...

Comment 12

[Martin Mokrejs]

I tried to reproduce this with current trunk nightly build of seamonkey 2.0a1pre after fixing the inconsistency in my preferences between mail.server.server2.directory and mail.server.server2.directory-rel pointing to "Local Folders" (uncovered in bug #452465). I removed ~/.mozilla/seamonkey/ and started seamonkey, it fired up migration wizard, converted all my folders but did not throw the error. Maybe that fixed the issue?


I ended up with:

$ find ~/.mozilla -name hostperm*
/home/mmokrejs/.mozilla/default/9o1z0pti.slt/hostperm.1
$ find ~/.mozilla -name cook*
/home/mmokrejs/.mozilla/default/9o1z0pti.slt/cookies.txt
/home/mmokrejs/.mozilla/seamonkey/99gpq0ix.default/cookies.sqlite-journal
/home/mmokrejs/.mozilla/seamonkey/99gpq0ix.default/cookies.sqlite
$ 

So no cookies and no host perms got copied, though.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b1pre) Gecko/20080924001030 SeaMonkey/2.0a1pre

Comment 13

[Martin Mokrejs]

I renamed ~/.mozilla/seamonkey/ and retried. Different result! Seee how the output of command changed during the import process and seamonkey2.0a1pre startup.

$ ./seamonkey &
[1] 22662
$ pwd
/home/mmokrejs/tmp/seamonkey-2.0a1pre.en-US.linux-i686-Sep24
$ find ~/.mozilla -name hostperm*
/home/mmokrejs/.mozilla/default/9o1z0pti.slt/hostperm.1
/home/mmokrejs/.mozilla/seamonkey/mk0bh9lh.default/hostperm.1
$ find ~/.mozilla -name hostperm*
/home/mmokrejs/.mozilla/default/9o1z0pti.slt/hostperm.1
/home/mmokrejs/.mozilla/seamonkey/mk0bh9lh.default/hostperm.1
$ find ~/.mozilla -name hostperm*
/home/mmokrejs/.mozilla/default/9o1z0pti.slt/hostperm.1
/home/mmokrejs/.mozilla/seamonkey/mk0bh9lh.default/hostperm.1
$ find ~/.mozilla -name cook*
/home/mmokrejs/.mozilla/seamonkey-/99gpq0ix.default/cookies.sqlite-journal
/home/mmokrejs/.mozilla/seamonkey-/99gpq0ix.default/cookies.sqlite
/home/mmokrejs/.mozilla/default/9o1z0pti.slt/cookies.txt
/home/mmokrejs/.mozilla/seamonkey/mk0bh9lh.default/cookies.txt
$ find ~/.mozilla -name cook*
/home/mmokrejs/.mozilla/seamonkey-/99gpq0ix.default/cookies.sqlite-journal
/home/mmokrejs/.mozilla/seamonkey-/99gpq0ix.default/cookies.sqlite
/home/mmokrejs/.mozilla/default/9o1z0pti.slt/cookies.txt
/home/mmokrejs/.mozilla/seamonkey/mk0bh9lh.default/cookies.txt
/home/mmokrejs/.mozilla/seamonkey/mk0bh9lh.default/cookies.sqlite
$ find ~/.mozilla -name hostperm*
/home/mmokrejs/.mozilla/default/9o1z0pti.slt/hostperm.1
$ find ~/.mozilla -name cook*
/home/mmokrejs/.mozilla/seamonkey-/99gpq0ix.default/cookies.sqlite-journal
/home/mmokrejs/.mozilla/seamonkey-/99gpq0ix.default/cookies.sqlite
/home/mmokrejs/.mozilla/default/9o1z0pti.slt/cookies.txt
/home/mmokrejs/.mozilla/seamonkey/mk0bh9lh.default/cookies.txt
/home/mmokrejs/.mozilla/seamonkey/mk0bh9lh.default/cookies.sqlite
$ ls -la /home/mmokrejs/.mozilla/seamonkey-/99gpq0ix.default/cookies*
-rw------- 1 mmokrejs mmokrejs 55296 Sep 24 23:45 /home/mmokrejs/.mozilla/seamonkey-/99gpq0ix.default/cookies.sqlite
-rw------- 1 mmokrejs mmokrejs     0 Sep 24 23:45 /home/mmokrejs/.mozilla/seamonkey-/99gpq0ix.default/cookies.sqlite-journal
$ ls -la /home/mmokrejs/.mozilla/default/9o1z0pti.slt/cookies*
-rw------- 1 mmokrejs mmokrejs 45160 Sep 24 23:20 /home/mmokrejs/.mozilla/default/9o1z0pti.slt/cookies.txt
$ ls -la /home/mmokrejs/.mozilla/seamonkey/mk0bh9lh.default/cookies*
-rw------- 1 mmokrejs mmokrejs     0 Sep 24 23:47 /home/mmokrejs/.mozilla/seamonkey/mk0bh9lh.default/cookies.sqlite
-rw------- 1 mmokrejs mmokrejs 45160 Sep 24 23:46 /home/mmokrejs/.mozilla/seamonkey/mk0bh9lh.default/cookies.txt
$ 
$ 
$ ls -la /home/mmokrejs/.mozilla/default/9o1z0pti.slt/hostperm*
-rw------- 1 mmokrejs mmokrejs 38110 Sep 24 21:00 /home/mmokrejs/.mozilla/default/9o1z0pti.slt/hostperm.1
$  find ~/.mozilla -name hostperm*
/home/mmokrejs/.mozilla/default/9o1z0pti.slt/hostperm.1
$ 
$  find ~/.mozilla -name hostperm* | xargs ls -la
-rw------- 1 mmokrejs mmokrejs 38110 Sep 24 21:00 /home/mmokrejs/.mozilla/default/9o1z0pti.slt/hostperm.1
$  find ~/.mozilla -name cookies* | xargs ls -la
-rw------- 1 mmokrejs mmokrejs 45160 Sep 24 23:20 /home/mmokrejs/.mozilla/default/9o1z0pti.slt/cookies.txt
-rw------- 1 mmokrejs mmokrejs 55296 Sep 24 23:45 /home/mmokrejs/.mozilla/seamonkey-/99gpq0ix.default/cookies.sqlite
-rw------- 1 mmokrejs mmokrejs     0 Sep 24 23:45 /home/mmokrejs/.mozilla/seamonkey-/99gpq0ix.default/cookies.sqlite-journal
-rw------- 1 mmokrejs mmokrejs     0 Sep 24 23:47 /home/mmokrejs/.mozilla/seamonkey/mk0bh9lh.default/cookies.sqlite
-rw------- 1 mmokrejs mmokrejs 45160 Sep 24 23:46 /home/mmokrejs/.mozilla/seamonkey/mk0bh9lh.default/cookies.txt
$ 

Do you have an explanation why .mozilla/seamonkey/mk0bh9lh.default/hostperm.1 got created and then disappeared? The cookies did not get converted because when I have accessed bugzilla.mozilla.org browser asked me to store the cookie. So effectively they do not exist in migrated profile. Yes, I see the zero size on the *sqlite* files, maybe that is the culprit?

But haven't seen the JavaScript error.

Comment 14

[Frank Wein [:mcsmurf]]

hostperm.1 is only used by the permissions manager to import the settings into permissions.sqlite as far as I know.

Comment 15

[Martin Mokrejs]

I just managed to import all my seamonkey-1.1.17 profile stuff into

Build identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.3pre) Gecko/20090801 SeaMonkey/2.0b2pre

$ find ~/.mozilla -name cookies* | xargs ls -la
-rw------- 1 mmokrejs mmokrejs 65462 Aug  1 01:59 /home/mmokrejs/.mozilla/default/9o1z0pti.slt/cookies.txt
-rw------- 1 mmokrejs mmokrejs 78848 Aug  1 09:45 /home/mmokrejs/.mozilla/seamonkey/prkqb1rn.default/cookies.sqlite
-rw------- 1 mmokrejs mmokrejs  3608 Aug  1 09:45 /home/mmokrejs/.mozilla/seamonkey/prkqb1rn.default/cookies.sqlite-journal
$ find ~/.mozilla -name hostperm* | xargs ls -la
-rw------- 1 mmokrejs mmokrejs 67937 Jul 31 21:14 /home/mmokrejs/.mozilla/default/9o1z0pti.slt/hostperm.1
$ find ~/.mozilla -name permiss* | xargs ls -la
-rw------- 1 mmokrejs mmokrejs 76800 Aug  1 09:10 /home/mmokrejs/.mozilla/seamonkey/prkqb1rn.default/permissions.sqlite
$

So I think this bug can be closed.

Comment 16

[Jens Hatlak (:InvisibleSmiley)]

Marking WFM as per reporter's comment 15.