trunk profile location might change again
Robert Kaiser
I had a longer discussion with Gerv from MoFo today and he took this
issue up on a MoFo conference call, and following that, we might change
the profile location on trunk once again.
The issue is https://bugzilla.mozilla.org/show_bug.cgi?id=393620 which
has been brought up by the OS/2 folks, but you might remember that lots
of people weren't too happy with us moving from "Mozilla"- to
"mozilla.org"-named directories for SeaMonkey.
Given we don't discover the vendor ID is shown anywhere in the UI
actually, and given that the SeaMonkey Council agrees, we might now
change this back to "Mozilla", which would place profiles in
"%APPDATA%\Mozilla\SeaMonkey\" on Windows and OS/2 and
"~/.mozilla/seamonkey/" on Linux (Mac ignores the vendor ID anyways).
I think nightly testers will be able to move their profiles over
manually when we really do this change.
Robert Kaiser
Andrew Schultz
> I think nightly testers will be able to move their profiles over
> manually when we really do this change.
Moving the profile is one thing, but parts of the profile specifically
reference the profile's absolute path (not a particularly great idea,
but it happens). Current files referencing the absolute path are:
prefs.js (mail.server.serverX.directory and mail.server.serverX.newsrc.file)
extensions.ini (apparently for profile-installed extensions)
panacea.dat
XUL.mfasl and history.dat also reference the absolute path, but I expect
that nothing bad will happen if they reference the wrong path.
--
Andrew Schultz
aj...@buffalo.edu
http://www.sens.buffalo.edu/~ajs42/
Robert Kaiser
> Robert Kaiser wrote:
>> I think nightly testers will be able to move their profiles over
>> manually when we really do this change.
>
> Moving the profile is one thing, but parts of the profile specifically
> reference the profile's absolute path (not a particularly great idea,
> but it happens).
Ah, true. Though I thought we had made prefs.js have relative paths and
using them preferably even if absolute ones are still present as a fallback.
Anyways, a migrator just for nightly testers doesn't sound like
something that makes sense.
Robert Kaiser
Andrew Schultz
> Andrew Schultz wrote:
>> Robert Kaiser wrote:
>>> I think nightly testers will be able to move their profiles over
>>> manually when we really do this change.
>>
>> Moving the profile is one thing, but parts of the profile specifically
>> reference the profile's absolute path (not a particularly great idea,
>> but it happens).
>
> Ah, true. Though I thought we had made prefs.js have relative paths and
> using them preferably even if absolute ones are still present as a
> fallback.
The capability to use relative paths exists, but parts of (all of?) mail
still don't use it.
> Anyways, a migrator just for nightly testers doesn't sound like
> something that makes sense.
So, what are you proposing happen with existing profiles in
~/.mozilla.org/ ?
Robert Kaiser
> So, what are you proposing happen with existing profiles in
> ~/.mozilla.org/ ?
I'd let them die as I have no better idea, am not able to write code
that does better and don't think only trunk using that location would
warrant such code.
Robert Kaiser
Michael Vincent van Rantwijk, MultiZilla
I agree, that should not be a problem.
Note: I always thought about mozilla.org to be the wrong one to use for
SeaMonkey (and I admit to have clicked on it when I was looking for the
other) so to me this is clearly a good change ;)
--
Michael Vincent van Rantwijk
- MultiZilla Project Team Lead
- XUL Boot Camp Staff member (ActiveState Training Partner)
- iPhone Application Developer
Andrew Schultz
I don't see how that's acceptable. If we're asking people to use trunk
for their normal use (and we do ask, and people do do it), we can't just say
"The mail you've received over the past few months is going away.
Enjoy! And you're welcome! (you didn't really want it anyway, did you?)"
Justin Wood (Callek)
> Robert Kaiser wrote:
>> Andrew Schultz wrote:
>>> So, what are you proposing happen with existing profiles in
>>> ~/.mozilla.org/ ?
>>
>> I'd let them die as I have no better idea, am not able to write code
>> that does better and don't think only trunk using that location would
>> warrant such code.
>
> I don't see how that's acceptable. If we're asking people to use trunk
> for their normal use (and we do ask, and people do do it), we can't just
> say
>
> "The mail you've received over the past few months is going away.
> Enjoy! And you're welcome! (you didn't really want it anyway, did you?)"
>
how trivial is the location issue's.
As in, could someone (easily) write a sed/batch/whatever script to load
on the *nightly* start-page notice, to download and run to migrate
(recent) trunk profiles.
I mean, all-in-all, I don't think there is much in the way we can do if
people want this change to happen. And I think it should.
Do we not agree that our trunk builds are and have always been "use at
own risk, features are possible to corrupt, erase, destroy your profile
data, saved passwords, file-system, migrate your OS from windows to OSX,
and even eat your grandmother" or some such paraphrase.
Yes, we have asked people to help test trunk builds, but imho, people
who are using trunk builds as their primary build, really should be
trusted to have backups and/or know how to correct this blemish (and/or
find out how to correct it).
~Justin Wood, (Callek)
Andrew Schultz
> how trivial is the location issue's.
>
> As in, could someone (easily) write a sed/batch/whatever script to load
> on the *nightly* start-page notice, to download and run to migrate
> (recent) trunk profiles.
A shell script should be able to handle the job (at least on unix,
probably mac). In addition to copying and doing a search/replace, it
would probably need to to migrate the bits from profiles.ini, which
would make it a bit more complex than it would otherwise need to be.
> I mean, all-in-all, I don't think there is much in the way we can do if
> people want this change to happen. And I think it should.
>
> Do we not agree that our trunk builds are and have always been "use at
> own risk, features are possible to corrupt, erase, destroy your profile
> data, saved passwords, file-system, migrate your OS from windows to OSX,
> and even eat your grandmother" or some such paraphrase.
Sure. But that doesn't mean we should drop their profile ("we did it
because we could"). There's a difference between doing something that
shouldn't have adverse effects (but might) and doing something that will
have adverse effects.
> Yes, we have asked people to help test trunk builds, but imho, people
> who are using trunk builds as their primary build, really should be
> trusted to have backups and/or know how to correct this blemish (and/or
> find out how to correct it).
Backups really wouldn't help. As far as correcting it goes, I suspect
some nightly users could fix it up. Others might find it a bit more
difficult. We certainly receive trunk bug reports from people who are
not all that technically savvy. And there are probably many more who
are even less savvy and don't report bugs.
Justin Wood (Callek)
> Justin Wood (Callek) wrote:
>> how trivial is the location issue's.
>>
>> As in, could someone (easily) write a sed/batch/whatever script to
>> load on the *nightly* start-page notice, to download and run to
>> migrate (recent) trunk profiles.
>
> A shell script should be able to handle the job (at least on unix,
> probably mac). In addition to copying and doing a search/replace, it
> would probably need to to migrate the bits from profiles.ini, which
> would make it a bit more complex than it would otherwise need to be.
>
If you (or anyone) could provide info on "what to do" in a bug, I'd be
willing to at least TRY to tackle this "trunk" migration script thing.
The idea here wouldn't be to make it 100% perfect, but to make it a
"best match" and a "manual run" for people.
>> I mean, all-in-all, I don't think there is much in the way we can do
>> if people want this change to happen. And I think it should.
>>
>> Do we not agree that our trunk builds are and have always been "use at
>> own risk, features are possible to corrupt, erase, destroy your
>> profile data, saved passwords, file-system, migrate your OS from
>> windows to OSX, and even eat your grandmother" or some such paraphrase.
>
> Sure. But that doesn't mean we should drop their profile ("we did it
> because we could"). There's a difference between doing something that
> shouldn't have adverse effects (but might) and doing something that will
> have adverse effects.
>
We'll still offer to migrate from old (1.x) SeaMonkey profiles, no?
>> Yes, we have asked people to help test trunk builds, but imho, people
>> who are using trunk builds as their primary build, really should be
>> trusted to have backups and/or know how to correct this blemish
>> (and/or find out how to correct it).
>
> Backups really wouldn't help. As far as correcting it goes, I suspect
> some nightly users could fix it up. Others might find it a bit more
> difficult. We certainly receive trunk bug reports from people who are
> not all that technically savvy. And there are probably many more who
> are even less savvy and don't report bugs.
>
How many *nightly* users are both not technically saavy, and use
nightlies for their PRIMARY/ONLY e-mail gathering?
I'm sure the number is miniscule, but I don't have hard numbers (if you
do, I'd be eager to hear where from).
Overall, sadly, I do not feel sorry for people who use nightlies as a
primary UA (especially for mail) and DO NOT file bugs or at least skim
newsgroups like this for important info.
Even in my day of using (near-solely) nightlies, I never used a nightly
as my sole mail source, I always kept backups in BOTH a release branch
of SeaMonkey (Suite at the time), and a downloaded copy of Thunderbird
(once it was available). I usually downloaded the mail to those
profiles about once a week, and backed up everything once a month, due
to my excessive nightly use.
~Justin Wood (Callek).
Philip Chee
> Given we don't discover the vendor ID is shown anywhere in the UI
> actually, and given that the SeaMonkey Council agrees, we might now
> change this back to "Mozilla", which would place profiles in
> "%APPDATA%\Mozilla\SeaMonkey\" on Windows and OS/2 and
> "~/.mozilla/seamonkey/" on Linux (Mac ignores the vendor ID anyways).
> I think nightly testers will be able to move their profiles over
> manually when we really do this change.
Hmm. (Win32) On branch, my profiles are in %APPDATA%\Mozilla\Profiles\*
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]Tagline temporarily out of order please use the stairs...
* TagZilla 0.066.6
Andrew Schultz
> If you (or anyone) could provide info on "what to do" in a bug, I'd be
> willing to at least TRY to tackle this "trunk" migration script thing.
Well, let's wait to see that this is actually going to happen
> The idea here wouldn't be to make it 100% perfect, but to make it a
> "best match" and a "manual run" for people.
Well, it should absolutely 100%
1. not mess up their old profile (easy)
2. not mess up any existing profile in ~/.mozilla/ (not very hard)
And it should also 100%
3. successfully migrate all "data" from old to new
Things like cache, preferences, cache, etc. are not so important, but
AFAICT, all that should "just work."
> We'll still offer to migrate from old (1.x) SeaMonkey profiles, no?
yes.
> How many *nightly* users are both not technically saavy, and use
> nightlies for their PRIMARY/ONLY e-mail gathering?
>
> I'm sure the number is miniscule, but I don't have hard numbers (if you
> do, I'd be eager to hear where from).
I don't have any numbers. I know that some of the developers and
primary QA folks do. Beyond that, there's no way to know. What I do
know is that dropping people's profiles is an excellent way to have
fewer testers when we need more.
> Overall, sadly, I do not feel sorry for people who use nightlies as a
> primary UA (especially for mail) and DO NOT file bugs or at least skim
> newsgroups like this for important info.
Some of them report problems in the newsgroups or in #seamonkey. Others
might report a serious problem if they encountered it, but don't.
> Even in my day of using (near-solely) nightlies, I never used a nightly
> as my sole mail source, I always kept backups in BOTH a release branch
> of SeaMonkey (Suite at the time), and a downloaded copy of Thunderbird
> (once it was available). I usually downloaded the mail to those
> profiles about once a week, and backed up everything once a month, due
> to my excessive nightly use.
Again, backups aren't relevant here. They don't help.
I don't really see us having reasonably quality if we don't have people
regularly using the builds. If all anyone does is to open a trunk
nightly now and then to see what's changed, then we're not going to have
many useful bug reports for trunk.
Philip Chee
Since these are nightly testers, post some example regexp (awk or sed or
perl) to handle these. I personally don't need to move my test profiles
because I use custom paths for all my SM/SR profiles so that they all
end up in %APPDIR%\Mozilla\Profiles\ (makes it easier to back them all
up in one go). All I probably need to do is to move profiles.ini (and
possibly /Crash Reports/) to the new location.
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]If you need a calculator, its too complex.
* TagZilla 0.066.6
Philip Chee
> Robert Kaiser wrote:
>> Andrew Schultz wrote:
>>> So, what are you proposing happen with existing profiles in
>>> ~/.mozilla.org/ ?
>> I'd let them die as I have no better idea, am not able to write code
>> that does better and don't think only trunk using that location would
>> warrant such code.
> I don't see how that's acceptable. If we're asking people to use trunk
> for their normal use (and we do ask, and people do do it), we can't just say
> "The mail you've received over the past few months is going away.
> Enjoy! And you're welcome! (you didn't really want it anyway, did you?)"
As long as profiles.ini is using absolute paths, copying it to the new
location should allow you to continue using your existing profiles.
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]OPERATER ERROR.. (A)bort, (R)etry, (G)ive up...
* TagZilla 0.066.6
Andrew Schultz
> As long as profiles.ini is using absolute paths, copying it to the new
> location should allow you to continue using your existing profiles.
Sure. But that doesn't happen by default. I guess we could copy
profiles.ini and absolutify the profile location(s). But that would
mean that existing trunk users would permanently have their profile in
the wrong spot.
Justin Wood (Callek)
> Justin Wood (Callek) wrote:
>> If you (or anyone) could provide info on "what to do" in a bug, I'd be
>> willing to at least TRY to tackle this "trunk" migration script thing.
>
> Well, let's wait to see that this is actually going to happen
>
IMO, it should. And if I read KaiRo's message right, it will.
(nevermind the countless requests for it)
>> The idea here wouldn't be to make it 100% perfect, but to make it a
>> "best match" and a "manual run" for people.
>
> Well, it should absolutely 100%
> 1. not mess up their old profile (easy)
> 2. not mess up any existing profile in ~/.mozilla/ (not very hard)
>
agreed.
> And it should also 100%
> 3. successfully migrate all "data" from old to new
>
Is my goal, but getting a script ready is not to be blocked on the
miniscule stuff (like absolutes in the xul fastload cache, or browser
cache if absolutes exist)
And I don't know if waiting for resolution on profile migration is worth
it here, we might as well start on figuring out where the issues lie,
and getting a script running for people who want to use it.
>> Overall, sadly, I do not feel sorry for people who use nightlies as a
>> primary UA (especially for mail) and DO NOT file bugs or at least skim
>> newsgroups like this for important info.
>
> Some of them report problems in the newsgroups or in #seamonkey. Others
> might report a serious problem if they encountered it, but don't.
>
>> Even in my day of using (near-solely) nightlies, I never used a
>> nightly as my sole mail source, I always kept backups in BOTH a
>> release branch of SeaMonkey (Suite at the time), and a downloaded copy
>> of Thunderbird (once it was available). I usually downloaded the mail
>> to those profiles about once a week, and backed up everything once a
>> month, due to my excessive nightly use.
>
> Again, backups aren't relevant here. They don't help.
>
They help in being able to retrieve old mail. they help in essence of
knowing exactly how much "might" be lost, and getting it back.
You also ass-u-me the data thats lost is need- data, that changed much
since they started using SuiteRunner. in Pop mail case it is possible,
yes, in every other case, only bookmarks can come close to the data-loss
situation. Pop Mail at least has retention options, (which I HIGHLY
encourage to anyone running a nightly). Bookmarks don't suffer the
copy-lossy situation.
> I don't really see us having reasonably quality if we don't have people
> regularly using the builds. If all anyone does is to open a trunk
> nightly now and then to see what's changed, then we're not going to have
> many useful bug reports for trunk.
>
Regularly using the builds does not equate to "using the builds as a
primary stability source". I would use mail&newsgroups when I could
from a nightly, but in the slightess sign of trouble, I'd utilize a
stable build in its place for a while, all the while getting my backups
going (even in the nightly, if possible)
~Justin Wood (Callek)
Steve Wendt
>> Ah, true. Though I thought we had made prefs.js have relative paths
>> and using them preferably even if absolute ones are still present as a
>> fallback.
>
> The capability to use relative paths exists, but parts of (all of?) mail
> still don't use it.
Is that still true in Thunderbird, as well? Or did they get it cleaned
up like the Firefox developers did, so it could be used on USB thumb
drives, etc.?
Tony Mechelynck
[...]
> How many *nightly* users are both not technically saavy, and use
> nightlies for their PRIMARY/ONLY e-mail gathering?
I'm not "very" tech savvy, and I "almost" scrapped Fx2+Tb2 in favour of Sm2
(not Sm1 which, among others, hasn't got a decent add-ons manager). However, I
had, call it a hunch, that Sm2 Mail/News wasn't quite as ready for prime time
yet as Sm2 Navigator and, especially, Sm2 chat. Apparently it's lucky for me
that I (temporarily?) stayed with Tb for mail/news. :-/
>
> I'm sure the number is miniscule, but I don't have hard numbers (if you
> do, I'd be eager to hear where from).
>
> Overall, sadly, I do not feel sorry for people who use nightlies as a
> primary UA (especially for mail) and DO NOT file bugs or at least skim
> newsgroups like this for important info.
>
> Even in my day of using (near-solely) nightlies, I never used a nightly
> as my sole mail source, I always kept backups in BOTH a release branch
> of SeaMonkey (Suite at the time), and a downloaded copy of Thunderbird
> (once it was available). I usually downloaded the mail to those
> profiles about once a week, and backed up everything once a month, due
> to my excessive nightly use.
>
> ~Justin Wood (Callek).
About the profile location moving: I seem to remember that it is possible to
have one's profile elsewhere than the default. Would it be a problem if, when
the (default) profile location is moved again, I tell SeaMonkey that I want my
profile to be at ~/.mozilla.org/seamonkey/zlzz68sw.default/ ? Wouldn't that be
the simplest and least error-prone way (for me) to handle it, keeping the
current "default" location as a future "custom" location?
Oh, and should I give (to the Profile Manager) the "custom" location's path
with or without the profile name itself?
Best regards,
Tony.
--
"No proper program contains an indication which as an operator-applied
occurrence identifies an operator-defining occurrence which as an
indication-applied occurrence identifies an indication-defining
occurrence different from the one identified by the given indication as
an indication-applied occurrence."
-- ALGOL 68 Report
Tony Mechelynck
[...]
> What I do
> know is that dropping people's profiles is an excellent way to have
> fewer testers when we need more.
> I don't really see us having reasonably quality if we don't have people
> regularly using the builds. If all anyone does is to open a trunk
> nightly now and then to see what's changed, then we're not going to have
> many useful bug reports for trunk.
>
I think the above is not only true but important to upholding the high quality
we strive for.
I'm not a developer, and my only involvement with QA is that I report bugs
when they bite me. (I don't p't'c'l'rly hunt for them.) I do use the
SeaMonkey/trunk navigator day-in day-out, as well as (in slightly different
roles) Firefox 2 and Konqueror (the latter primarily as a file manager but
also accessorily as a browser); I also use Firefox 3 and Lynx, but not every
day. For mail & news, I'm exclusively with Tb2 -- switching isn't as easy
there because I archive a significant proportion of my read mail. I think I'll
still wait a little, maybe until Sm2 beta.
I'm not going back to Sm1 anyway: if only because of its less-than-optimal
extension management, for me it's a goner.
Best regards,
Tony.
--
Maybe Computer Science should be in the College of Theology.
-- R. S. Barton
Andrew Schultz
>> Again, backups aren't relevant here. They don't help.
>
> They help in being able to retrieve old mail. they help in essence of
> knowing exactly how much "might" be lost, and getting it back.
Backups don't help in *this* instance because the profile data isn't
erased, it would simply be missing from the .mozilla/ profile.
> Regularly using the builds does not equate to "using the builds as a
> primary stability source". I would use mail&newsgroups when I could
> from a nightly, but in the slightess sign of trouble, I'd utilize a
> stable build in its place for a while, all the while getting my backups
> going (even in the nightly, if possible)
That's fine. I'm saying that if everyone did that, we'd get very little
feedback on most of mail functionality and quality would suffer.
--
Andrew Schultz
ajsc...@verizon.net
http://www.sens.buffalo.edu/~ajs42/
Tony Mechelynck
I read yesterday on the Mozillazine KB (now where was it? "Moving your profile
folder" or something linked from it?) that TB 1.5 and later _creates_ relative
paths when it makes a new profile, but that it will _use_ absolute paths (in
profiles migrated from Tb 1.0.x), when present, in preference to relative paths.
Best regards,
Tony.
--
A priest asked: What is Fate, Master?
And he answered:
It is that which gives a beast of burden its reason for existence.
It is that which men in former times had to bear upon their backs.
It is that which has caused nations to build byways from City to City
upon which carts and coaches pass, and alongside which inns have come
to be built to stave off Hunger, Thirst and Weariness.
And that is Fate? said the priest.
Fate ... I thought you said Freight, responded the Master.
That's all right, said the priest. I wanted to know what Freight was
too.
-- Kehlog Albran, "The Profit"
Rinaldi J. Montessi
> Sure. But that doesn't mean we should drop their profile ("we did it
> because we could"). There's a difference between doing something that
> shouldn't have adverse effects (but might) and doing something that will
> have adverse effects.
Isn't this exactly what happened when you switched from ~/.mozilla to
~/.mozilla.org? How much heat did that generate?
Rinaldi
--
Death is life's way of telling you you've been fired.
-- R. Geis
Andrew Schultz
> Andrew Schultz wrote:
>> mail still don't use it.
>
> Is that still true in Thunderbird, as well? Or did they get it cleaned
> up like the Firefox developers did, so it could be used on USB thumb
> drives, etc.?
Actually the relevant bug seems fixed:
https://bugzilla.mozilla.org/show_bug.cgi?id=137006
It looks like both relative and absolute paths are stored in prefs.js.
Based on the patch in that bug, for reading prefs, the relative path is
used if found and absolute paths are used only as a fallback. For
writing prefs, both are written.
So a brute-force copy of the profile (with manual editing of
profiles.ini) would result in panacea.dat loss (not sure what losing
that would mean).
Sailfish
--
Sailfish - Netscape/Mozilla Champion
Netscape/Mozilla Tips: http://www.ufaq.org/ , http://ilias.ca/
mozilla-based Themes: http://www.projectit.com/freestuff.html
Philip Chee
> So a brute-force copy of the profile (with manual editing of
> profiles.ini) would result in panacea.dat loss (not sure what losing
> that would mean).
My SR profiles are in a non-standard location. I don't need them
brute-force copied /anywhere/ thankyouverymuch.
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]If it's obvious, it's obviously wrong.
* TagZilla 0.066.6
Andrew Schultz
> Isn't this exactly what happened when you switched from ~/.mozilla to
> ~/.mozilla.org? How much heat did that generate?
No, for that switch, Standard8 got the profile migrator working to the
point that most all of the bits that could be safely migrated were
migrated. There were other parts of the profile that various people
asserted ought to be migrated, but these were higher risk and/or lower
reward parts (and AFAIK, nobody wrote patches to migrate those parts).
Rinaldi J. Montessi
> Rinaldi J. Montessi wrote:
>> Isn't this exactly what happened when you switched from ~/.mozilla to
>> ~/.mozilla.org? How much heat did that generate?
>
> No, for that switch, Standard8 got the profile migrator working to the
> point that most all of the bits that could be safely migrated were
> migrated. There were other parts of the profile that various people
> asserted ought to be migrated, but these were higher risk and/or lower
> reward parts (and AFAIK, nobody wrote patches to migrate those parts).
Perhaps there was a dead zone somewhere in that time frame because I had
to move the contents of Local Folders, bookmarks and address book
(others?) from the .mozilla to .mozilla.org directory. I was
particularly annoyed that I couldn't just point the profile manager to
my existing files. Dot files (hidden) do not appear in the profile
selection window, and the "Show Hidden Files" checkbox is not available
until the ui preference in prefs.js can be toggled. A Catch 22 it seems.
Not a big deal and I expect these kinds of things to happen when I do my
own CVS builds.
Rinaldi
--
There's no real need to do housework -- after four years it doesn't get
any worse.
Peter Weilbacher
> Robert Kaiser wrote:
>> manually when we really do this change.
>
> reference the profile's absolute path (not a particularly great idea,
>
> prefs.js (mail.server.serverX.directory and mail.server.serverX.newsrc.file)
> extensions.ini (apparently for profile-installed extensions)
> panacea.dat
>
> XUL.mfasl and history.dat also reference the absolute path, but I expect
> that nothing bad will happen if they reference the wrong path.
I don't see a big problem with moving back for trunk if at the point when
the switchover happens, someone announces that (at least here, on the SM
blog, and possibly in the MozillaZine forums), and points to some short
guidelines how to properly move the profile back by hand. As a starting
point, this is what I just did on Linux:
(edit application.ini to change vendor ID from mozilla.org to mozilla)
cd ~/.mozilla
cp -a ~/.mozilla.org/seamonkey/ .
rm seamonkey/*.default/XUL.mfasl seamonkey/*.default/XPC.mfasl seamonkey/*.default/panacea.dat
rm seamonkey/*.default/xpti.dat seamonkey/*.default/compreg.dat
perl -pe 's,/\.mozilla.org/,/.mozilla/,g' -iBAK \
seamonkey/*.default/extensions.ini seamonkey/*.default/prefs.js seamonkey/*.default/user.js
mv ~/.mozilla.org/ ~/.mozilla.org_saved
Seems to work fine. (The last line is just to check that it really worked
and that the moved profile is taken up and not the one in .mozilla.org.)
I think that most nightly users should be able to follow something like
this and those few that cannot probably know where to ask in case of
problems.
Peter.
Jaisen
> So a brute-force copy of the profile (with manual editing of
> profiles.ini) would result in panacea.dat loss (not sure what losing
> that would mean).
Well if the user has to brute-force copy the profile and manually edit
the profiles.ini so as to contain the new path, would it really be
that much more work to simply open the other 3 files in any text
editor and use the replace command to automatically swap the old path
for the new one? Wouldn't that guarantee that there is no data loss?
If so, it shouldn't be too hard to provide some simple instructions to
those non-techy types to follow.
Also Andrew, as an everyday user of SM2 with no alternative (FF,SM1 or
TB), I truly appreciate your concern. It's nice to know some are
concerned for those willing to take the risks (small as they may be)
in order to help move the program forward (foolish and generally
incompetent as we may be).
Peter Weilbacher
> So a brute-force copy of the profile (with manual editing of
> profiles.ini) would result in panacea.dat loss (not sure what losing
> that would mean).
My guess is nothing would be lost. Not sure if all the information like
http://kb.mozillazine.org/Phantom_folders
http://www.holgermetzger.de/pdl.html
is still 100% up to date but it never caused me any problems to remove it.
Searching for panacea on MXR confirms that it is still used as a folder
cache.
Peter.
Robert Kaiser
> How many *nightly* users are both not technically saavy, and use
> nightlies for their PRIMARY/ONLY e-mail gathering?
Actually, IMHO, none should be, as we don't encourage any non-tech-savvy
user to *use* a pre-alpha version.
Robert Kaiser
Robert Kaiser
> A shell script should be able to handle the job (at least on unix,
> probably mac).
Non, not on Mac, as Mac doesn't have a profile location change. Only
Linux and Windows have.
Mac ignores the vendor ID completely for the profile path.
Robert Kaiser
Robert Kaiser
> Also Andrew, as an everyday user of SM2 with no alternative (FF,SM1 or
> TB), I truly appreciate your concern. It's nice to know some are
> concerned for those willing to take the risks (small as they may be)
> in order to help move the program forward (foolish and generally
> incompetent as we may be).
Well, the main reason why I posted here (and intend to post again when
it happens, with a cross-post to the support group, as well as a blog
post) is because I hope we should reach the majority of nightly testers
this way and as I hoped a manual copy/move of the profile dir is
something that 1) works and 2) should be something a nightly tester
should know how to do.
I wouldn't do it this way for users of a stable version, but we don't
even have an Alpha with the mozilla.org profile location yet, so it's
still doable that way IMHO.
Robert Kaiser
Robert Kaiser
> Will there be a thread announcing when the switchover occurs?
Yes, I intend to post here and on the support group with a followup to
here, as well as do a post on my blog.
BTW, Council has voted for this change, so I'm only waiting on the
outcome of the discussion here.
Robert Kaiser
Justin Wood (Callek)
exactly my point :-P
~Justin Wood (Callek)
Sailfish
Justin Wood (Callek)
If someone could detail the stuff that needs migrating (specifically)
[can we ass-u-me the extensions themselves should be re-installed?]
What files should be ignored (as in auto-regenerated stuff, cache, etc.)
Should we "nuke" the old profile, or rename the dir etc.?
What files need (or could need) changes, such as rel/abs path info? And
where and what in such files.
We can get a script/help-doc created that does this work.
~Justin Wood (Callek)
Sailfish
the change (along with making the needed relative path changes), I would
highly recommend not nuking the old profile or even renaming it (maybe a
rename to something like "./mozilla.orgDEPRECATED/" or some such?). I
can't say for others but I've tweaked my prefs.js file, especially in
areas having to do with mailnews paths, and would not want to have to
recreate all of that from scratch in the event that it was nuked and I
hadn't saved it.
As for writing a tool to convert the old to the new, if that's done, I'd
make its use an optional user invocation.
Justin Wood (Callek)
Since this is a nightly user crowd, when we don't have even an alpha
yet. This tool would be *strictly* presented to nightly users, as a
means to copy the data over, and invoked *manually* to do so.
If you want to start your profile from scratch, or re-import from your
last install of SeaMonkey, thats fine too (imho).
The concept of me (or anyone) doing a tool/script/help-docs to get this
done is to satisfy the (few) who proclaim its needed. (even though I
have my personal doubts on the numbers of people who it would actually
affect)
~Justin Wood (Callek)
Andrew Schultz
> While I've already copied my existing profile over in anticipation of
> the change (along with making the needed relative path changes), I would
> highly recommend not nuking the old profile or even renaming it (maybe a
> rename to something like "./mozilla.orgDEPRECATED/" or some such?). I
I can't think of any reason to remove or rename the old profile
location, except perhaps to not waste space. If someone uses a build
from the day after the switch and it's broken, they should be able to go
back. And/or people should be able to test nightly builds that use
~/.mozilla.org/ (to identify regression windows).
Justin Wood (Callek)
> Sailfish wrote:
>> While I've already copied my existing profile over in anticipation of
>> the change (along with making the needed relative path changes), I
>> would highly recommend not nuking the old profile or even renaming it
>> (maybe a rename to something like "./mozilla.orgDEPRECATED/" or some
>> such?). I
>
> I can't think of any reason to remove or rename the old profile
> location, except perhaps to not waste space. If someone uses a build
> from the day after the switch and it's broken, they should be able to go
> back. And/or people should be able to test nightly builds that use
> ~/.mozilla.org/ (to identify regression windows).
>
fair enough, was just a question I posed; so we can try to get this
"done" and that bug resolved sooner than later (IE. the sooner its done,
the theoretical less people who are affected)
~Justin Wood (Callek)
Michael Vincent van Rantwijk, MultiZilla
> Robert Kaiser wrote:
>> Sailfish wrote:
>>> Will there be a thread announcing when the switchover occurs?
>>
>> Yes, I intend to post here and on the support group with a followup to
>> here, as well as do a post on my blog.
>>
>> BTW, Council has voted for this change, so I'm only waiting on the
>> outcome of the discussion here.
>>
>> Robert Kaiser
>>
>
> If someone could detail the stuff that needs migrating (specifically)
> [can we ass-u-me the extensions themselves should be re-installed?]
>
> What files should be ignored (as in auto-regenerated stuff, cache, etc.)
>
> Should we "nuke" the old profile, or rename the dir etc.?
NO! Don't remove or rename a perfectly valid directory name just because
a newer version needs a different path, because it can be left there for
perfectly valid reasons.
--
Michael Vincent van Rantwijk
- MultiZilla Project Team Lead
- XUL Boot Camp Staff member (ActiveState Training Partner)
- iPhone Application Developer
Sailfish
> Sailfish wrote:
>> While I've already copied my existing profile over in anticipation of
>> the change (along with making the needed relative path changes), I
>> would highly recommend not nuking the old profile or even renaming it
>> (maybe a rename to something like "./mozilla.orgDEPRECATED/" or some
>> such?). I
>
> I can't think of any reason to remove or rename the old profile
> location, except perhaps to not waste space. If someone uses a build
> from the day after the switch and it's broken, they should be able to go
> back. And/or people should be able to test nightly builds that use
> ~/.mozilla.org/ (to identify regression windows).
>
looking for their SM2 profile later that it's no longer located there
but I can also see an argument to leave it, too.
Jaisen
> it happens, with a cross-post to the support group, as well as a blog
> post) is because I hope we should reach the majority of nightly testers
> this way and as I hoped a manual copy/move of the profile dir is
> something that 1) works and 2) should be something a nightly tester
> should know how to do.
> I wouldn't do it this way for users of a stable version, but we don't
> even have an Alpha with the mozilla.org profile location yet, so it's
> still doable that way IMHO.
>
> Robert Kaiser
Indeed. Further, I certainly did not mean to tacitly chide you, or any
other hard working, SM developer. Your work is highly appreciated. My
side remark was merely to encourage Andrew's considerateness.
Jaisen
> it happens, with a cross-post to the support group, as well as a blog
> post) is because I hope we should reach the majority of nightly testers
> this way and as I hoped a manual copy/move of the profile dir is
> something that 1) works and 2) should be something a nightly tester
> should know how to do.
> I wouldn't do it this way for users of a stable version, but we don't
> even have an Alpha with the mozilla.org profile location yet, so it's
> still doable that way IMHO.
>
> Robert Kaiser
Indeed. Further, I certainly did not mean to tacitly chide you, or any
Robert Kaiser
> We can get a script/help-doc created that does this work.
Anything happening in this area?
I'd like not not move this patch/checkin out indefinitely...
Robert Kaiser
Robert Kaiser
> Robert Kaiser wrote:
>> I think nightly testers will be able to move their profiles over
>> manually when we really do this change.
>
> Moving the profile is one thing, but parts of the profile specifically
> reference the profile's absolute path (not a particularly great idea,
> but it happens).
FYI, I just did the change locally (it's easy, as it's only in
application.ini which is a simple text file even in a binary build, so
anyone can test this), and I did a simple move of the "seamonkey" subdir
from ~/.mozilla.org over to ~/.mozilla, and everything works fine.
Robert Kaiser
Andrew Schultz
> I don't see a big problem with moving back for trunk if at the point when
> the switchover happens, someone announces that (at least here, on the SM
> blog, and possibly in the MozillaZine forums), and points to some short
> guidelines how to properly move the profile back by hand. As a starting
> point, this is what I just did on Linux:
>
> (edit application.ini to change vendor ID from mozilla.org to mozilla)
> cd ~/.mozilla
What if ~/.mozilla doesn't exist? Not exactly likely, but easy to handle.
> cp -a ~/.mozilla.org/seamonkey/ .
What if someone already tried to use a new trunk build without
migrating? This makes things more complicated, but I expect this will
be the most common case (someone tries a build, their profile is gone
and eventually they poke around and find out what happened and get this
script).
Ideally, the script would migrate a single profile (if a profile by the
same name doesn't already exist). But that can be significantly more
complicated.
> rm seamonkey/*.default/XUL.mfasl seamonkey/*.default/XPC.mfasl seamonkey/*.default/panacea.dat
what is the effect of deleting panacea.dat. I expect it won't be
catastrophic, but I haven't had time to investigate.
> rm seamonkey/*.default/xpti.dat seamonkey/*.default/compreg.dat
> perl -pe 's,/\.mozilla.org/,/.mozilla/,g' -iBAK \
> seamonkey/*.default/extensions.ini seamonkey/*.default/prefs.js seamonkey/*.default/user.js
So... my homepage that used to be "http://www.mozilla.org/" is now
"http://www.mozilla/". Oops. Probably not a huge deal. Messing up
other URLs might have more dire consequences.
This could be avoided by either matching $HOME/.mozilla or by matching
only lines we know need to change (although that's a bit scarier).
Also, what if my profile isn't named default?
> mv ~/.mozilla.org/ ~/.mozilla.org_saved
As I said before, we probably shouldn't do this by default. If some QA
person wants to verify that the patch worked, they can do this manually.
Other people should be able to switch back to their old build and
profile without extra work.
> Seems to work fine. (The last line is just to check that it really worked
> and that the moved profile is taken up and not the one in .mozilla.org.)
> I think that most nightly users should be able to follow something like
> this and those few that cannot probably know where to ask in case of
> problems.
Yes, I'm not sure whether a simple script that someone might need to
customize to their own profile would work better than a
singing-all-dancing script that everyone could just run. For instance,
would someone recognize that they couldn't use your "cp" line if they
already had a profile in ~/.mozilla/seamonkey/ ? Or that they need to
change all instances of "*.default" to "*.profilename" if it's not named
default?
Andrew Schultz
> On Fri, 31 Aug 2007 16:00:50 UTC, Robert Kaiser wrote:
>
>> Justin Wood (Callek) wrote:
>>> We can get a script/help-doc created that does this work.
>> Anything happening in this area?
>
> <46D53D6C...@gaston.Weilbacher.org>. Haven't gotten even one
> reaction on it. I cannot adapt it for Win and Mac because I don't have
> those systems around and I am not sure what tools are normally available
> on those OSs.
I was waiting to know that the change was actually going to happen
before spending to much time debugging a script (I just did reply to
your original post).
From bug 393620, it looks like we will be making the change...
Robert Kaiser
> So... my homepage that used to be "http://www.mozilla.org/" is now
> "http://www.mozilla/". Oops. Probably not a huge deal.
The default homepage in our profiles is
http://www.mozilla.org/projects/seamonkey/start/ - we should at least
not break that one.
Robert Kaiser
Robert Kaiser
> I cannot adapt it for Win and Mac
As I already said, forget Mac, it ignores the vendor ID for profiles
anyways, so nothing changes there.
Robert Kaiser
Justin Wood (Callek)
Maybe we can proclaim that as our solution, and simply add a "for
additional help with unlikely profile problems, join us in #seamonkey,
or ask on the <link>newsgroup</link>" or some such.
If "move" in its most common circumstances will allow things to work right.
(We should advocate copy though, imho)
~Justin Wood (Callek)
Jaisen
> catastrophic, but I haven't had time to investigate.
I tried this out to see. First result, SM loaded much faster. Second,
the only difference I noticed was in the mailnews component, in the
left hand column, rather than by default having all my accounts with
the expanded view, local folders was collapsed. All else remained the
same and the panacea.dat was rebuilt, this time without having the
elaborate history it first did.
Neil
> Peter Weilbacher wrote:
>
>> rm seamonkey/*.default/xpti.dat seamonkey/*.default/compreg.dat
>> perl -pe 's,/\.mozilla.org/,/.mozilla/,g' -iBAK \
>> seamonkey/*.default/extensions.ini seamonkey/*.default/prefs.js
>> seamonkey/*.default/user.js
>
> So... my homepage that used to be "http://www.mozilla.org/" is now
> "http://www.mozilla/".
No, it would have to be http://.mozilla.org/ to match the regexp
(although the second . isn't quoted so http://.mozillaborg/ would also
match).
--
Warning: May contain traces of nuts.
Andrew Schultz
> Andrew Schultz wrote:
>> So... my homepage that used to be "http://www.mozilla.org/" is now
>> "http://www.mozilla/".
>
> No, it would have to be http://.mozilla.org/ to match the regexp
> (although the second . isn't quoted so http://.mozillaborg/ would also
> match).
Ah, right. I think I knew that on some level. Apparently not the
typing level. :) OK, so the regexp could be cleaned up a bit, but
probably doesn't need the extra bits I mentioned.
--
Andrew Schultz
ajsc...@verizon.net
http://www.sens.buffalo.edu/~ajs42/
Peter Weilbacher
> (although the second . isn't quoted so http://.mozillaborg/ would also
> match).
Oops...
P.
Peter Weilbacher
> Peter Weilbacher wrote:
>> I don't see a big problem with moving back for trunk if at the point when
>> the switchover happens, someone announces that (at least here, on the SM
>> blog, and possibly in the MozillaZine forums), and points to some short
>> guidelines how to properly move the profile back by hand. As a starting
>> point, this is what I just did on Linux:
>>
>> (edit application.ini to change vendor ID from mozilla.org to mozilla)
>> cd ~/.mozilla
>
> What if ~/.mozilla doesn't exist? Not exactly likely, but easy to handle.
Yep.
>> cp -a ~/.mozilla.org/seamonkey/ .
>
> What if someone already tried to use a new trunk build without
> migrating? This makes things more complicated, but I expect this will
> be the most common case (someone tries a build, their profile is gone
> and eventually they poke around and find out what happened and get this
> script).
Just give up in that case with an error message?
> Ideally, the script would migrate a single profile (if a profile by the
> same name doesn't already exist). But that can be significantly more
> complicated.
Yes, then one would have to start parsing profiles.ini in the script.
Not something I want to do.
>> rm seamonkey/*.default/XUL.mfasl seamonkey/*.default/XPC.mfasl seamonkey/*.default/panacea.dat
>
> what is the effect of deleting panacea.dat. I expect it won't be
> catastrophic, but I haven't had time to investigate.
Nothing really as Jaisen noticed in the meantime. It's just a misnamed cache
file that is rebuilt when absent.
>> rm seamonkey/*.default/xpti.dat seamonkey/*.default/compreg.dat
>> perl -pe 's,/\.mozilla.org/,/.mozilla/,g' -iBAK \
>> seamonkey/*.default/extensions.ini seamonkey/*.default/prefs.js seamonkey/*.default/user.js
>
> So... my homepage that used to be "http://www.mozilla.org/" is now
> "http://www.mozilla/". Oops. Probably not a huge deal. Messing up
> other URLs might have more dire consequences.
>
> This could be avoided by either matching $HOME/.mozilla or by matching
> only lines we know need to change (although that's a bit scarier).
>
> Also, what if my profile isn't named default?
Perhaps one should loop through the profile directories after copying.
>> mv ~/.mozilla.org/ ~/.mozilla.org_saved
>
> As I said before, we probably shouldn't do this by default.
Agreed.
>> Seems to work fine. (The last line is just to check that it really worked
>> and that the moved profile is taken up and not the one in .mozilla.org.)
>> I think that most nightly users should be able to follow something like
>> this and those few that cannot probably know where to ask in case of
>> problems.
>
> Yes, I'm not sure whether a simple script that someone might need to
> customize to their own profile would work better than a
> singing-all-dancing script that everyone could just run. For instance,
> would someone recognize that they couldn't use your "cp" line if they
> already had a profile in ~/.mozilla/seamonkey/ ? Or that they need to
> change all instances of "*.default" to "*.profilename" if it's not named
> default?
See above. Tried to implement that in the script below. It's surely not
good enough to handle all possible cases, but it should cover most of them,
hopefully without causing any damage.
P.
#!/bin/bash
if [ ! -d ~/.mozilla ] ; then
mkdir -p ~/.mozilla
fi
cd ~/.mozilla
if [ -d ~/.mozilla/seamonkey ] ; then
echo "There already appears to be a subdirectory ~/.mozilla/seamonkey"
echo "Please copy your profile manually!"
exit 1
fi
echo "Copying everything from ~/.mozilla.org/seamonkey to ~/.mozilla/seamonkey"
cp -a ~/.mozilla.org/seamonkey/ . || (echo "Error copying profile data!" ; exit 2)
# profile dirs should have a dot in the middle
for PROFDIR in `find seamonkey/ -maxdepth 1 -type d -name "*.*"`
do
echo "Adapting paths in profile \"$PROFDIR\""
rm $PROFDIR/XUL.mfasl $PROFDIR/XPC.mfasl $PROFDIR/panacea.dat \
$PROFDIR/xpti.dat $PROFDIR/compreg.dat
perl -pe 's,/\.mozilla\.org/,/.mozilla/,g' -iBAK \
$PROFDIR/extensions.ini $PROFDIR/prefs.js $PROFDIR/user.js
done
Andrew Schultz
> Yes, then one would have to start parsing profiles.ini in the script.
> Not something I want to do.
Sure, I understand. But isn't this going to be the most common case?
> See above. Tried to implement that in the script below. It's surely not
> good enough to handle all possible cases, but it should cover most of them,
> hopefully without causing any damage.
The script looks OK (except I'd like some way to work for people with an
existing ~/.mozilla/seamonkey). I went back and looked through my
profile directory for references to .mozilla.org and discovered that
some of my profiles referenced the profile directory from within
secmod.db. It's a binary NSS database. And the worst part is that the
secmod.db in the profile I looked at before didn't reference the profile
because... it referenced my old xpfe profile directory
(~/.mozilla/default/XXXXXXX.slt/). So this didn't get migrated from
that change. Apparently it's not catastrophic. :/
Andrew Schultz
> Peter Weilbacher wrote:
>> Yes, then one would have to start parsing profiles.ini in the script.
>> Not something I want to do.
>
> Sure, I understand. But isn't this going to be the most common case?
This is my attempt at handling profiles.ini. It seems to work OK.
Tony Mechelynck
[...]
Looks nice; but only for Unix-like systems and only with Perl installed.
I suppose a similar script ought to be written for Windows, but the paths are
different and the "typical" interpreter (cmd.exe) is considerably less powerful.
Let's give it a try. I'm moving, not copying, because I don't remember how to
copy a directory recusively in command.com
Please check: I'm on Linux now, and my memory of Dos batch language is rusty.
Let's hope the start-of-line colons (labels) won't be changed into quote marks
by the mailer.
I'm assuming both scripts below will be put in the PATH.
____moveprf.bat
cd %APPDATA%
if not exist Mozilla\NUL md Mozilla
if exist Mozilla\nul goto have_Mozilla
echo Cannot create %APPDATA%\Mozilla
exit 3
:have_Mozilla
cd Mozilla
if not exist seamonkey\NUL goto move_profile
echo There appears to be a %APPDATA%\Mozilla\seamonkey subdirectory already
echo Please copy your profile manually
echo or -- if you don't need it -- delete %APPDATA%\Mozilla\seamonkey
echo then retry
exit 1
:move_profile
echo Move %APPDATA%\.mozilla.org\seamonkey
echo to %APPDATA%\Mozilla\seamonkey
cd ..
ren .mozilla.org\seamonkey Mozilla\seamonkey
if not errorlevel 1 goto moved
echo Error moving profile data!
exit 2
:moved
cd Mozilla\seamonkey
for %%a in *.* do if exist %%a\NUL call cleanprf.bat %%a
____moveprf.bat end
____cleanprf.bat
cd %1
if errorlevel 1 exit 1
echo Adapting paths in %1
if not exist parent.lock goto ok
echo Profile seems to be in use! Aborting.
exit 1
:ok
del /Y xul.mfasl xpc.mfasl panacea.dat xpti.dat compreg.dat
rem add code here to replace .mozilla.org by Mozilla in
rem extensions.ini prefs.js user.js
rem the following might work if gvim is installed, but
rem of course we can't guarantee that. Is Perl any likelier?
rem the following is one long line
gvim -esN -c "set awa" -c "argdo 1,$s/\.mozilla\.org\>/Mozilla/g" -cq
extensions.ini prefs.js user.js
rem the above is one long line
____cleanprf.bat end
Best regards,
Tony.
--
Always borrow money from a pessimist; he doesn't expect to be paid
back.
Peter Weilbacher
> This is my attempt at handling profiles.ini. It seems to work OK.
Clearly more sophisticated than my approach. :-)
> if [ -d ~/.mozilla.org/seamonkey ]; then
> # look again in the new location.
> profdirnew=`find ~/.mozilla/seamonkey/ -name "*.${1}" -printf %f`
>
> if [ -n "$profdir" ]; then
This should be "$profdirnew".
The problem with the awk script is that it searches for a profile with
Name equal to the first argument. My default profile for some reason
has Name=Peter but Path=<slt>.default (probably something to do with
the suiterunner migrator). That has the effect that the profile is
copied but profiles.ini only get a new [ProfileX] line but nothing else.
To still find the correct profile in profiles.ini, I think one should
change
if (/^Name/) {
split($0,name,"=");
if (name[2] == profname) {
found=1; print;
}
}
to
if (/^Name/) { name=$0; }
if (/^IsRelative/) { isRel=$0; }
if (/^Path/) {
split($0,path,".");
if (path[2] == profname) {
found=1;
print name;
print isRel;
print;
}
At least that works here, probably there is a more clever awk-way
to print the two precending lines...
Peter.
Peter Weilbacher
> :move_profile
> echo Move %APPDATA%\.mozilla.org\seamonkey
Is it really called .mozilla.org on Windows at the moment with the
leading dot?
> echo to %APPDATA%\Mozilla\seamonkey
> cd ..
> ren .mozilla.org\seamonkey Mozilla\seamonkey
[...]
> del /Y xul.mfasl xpc.mfasl panacea.dat xpti.dat compreg.dat
> rem add code here to replace .mozilla.org by Mozilla in
> rem extensions.ini prefs.js user.js
> rem the following might work if gvim is installed, but
> rem of course we can't guarantee that. Is Perl any likelier?
[...]
> gvim -esN -c "set awa" -c "argdo 1,$s/\.mozilla\.org\>/Mozilla/g" -cq extensions.ini prefs.js user.js
On the Windows systems that I have seen GVim is as unlikely to be
installed as any other tool that can automatically do replacements
like this (or I have missed them, I only rarely use Win).
Perhaps it is then better to simply instruct people what to edit,
like
- use Notepad to edit the files
extensions.ini prefs.js user.js
if they exist and replace all instances of \\mozilla.org\\
with \\Mozilla\\
But then there are probably those instances with forward slashes,
too, user.js is likely to not exist, and editing may be more destructive
than not, and more confusing...
Peter.
Neil
>Tony Mechelynck wrote:
>
>>:move_profile
>>echo Move %APPDATA%\.mozilla.org\seamonkey
>>
>>
>Is it really called .mozilla.org on Windows at the moment with the leading dot?
>
>
Not on Windows, no... maybe that was a bad port from Linux, where the
name is lowercased and dot-prefixed.
Tony Mechelynck
well, then
echo .
echo You must do the following by hand:
echo edit the files:
echo - extensions.ini
if exist user.js echo - user.js
echo - prefs.js
echo replacing everywhere ".mozilla.org" by "Mozilla"
echo in directory paths.
echo .
echo Please do it now, then hit Enter to continue
pause
Best regards,
Tony.
--
Ah say, son, you're about as sharp as a bowlin' ball.
Andrew Schultz
> Andrew Schultz wrote:
>> if [ -d ~/.mozilla.org/seamonkey ]; then
>> # look again in the new location.
>> profdirnew=`find ~/.mozilla/seamonkey/ -name "*.${1}" -printf %f`
>>
>> if [ -n "$profdir" ]; then
>
> This should be "$profdirnew".
right!
> The problem with the awk script is that it searches for a profile with
> Name equal to the first argument. My default profile for some reason
> has Name=Peter but Path=<slt>.default (probably something to do with
> the suiterunner migrator). That has the effect that the profile is
> copied but profiles.ini only get a new [ProfileX] line but nothing else.
Hmm. What exactly does your profile.ini section look like?
Peter Weilbacher
> Peter Weilbacher wrote:
>
>> Name equal to the first argument. My default profile for some reason
>> has Name=Peter but Path=<slt>.default (probably something to do with
>> the suiterunner migrator). That has the effect that the profile is
>> copied but profiles.ini only get a new [ProfileX] line but nothing else.
>
> Hmm. What exactly does your profile.ini section look like?
[Profile0]
Name=Peter
IsRelative=1
Path=gmrsva54.default
Default=1
As the script uses the actual path of the profile to confirm that the
profile is there and not yet copied, I think it would make sense to
use the path to find it in profiles.ini, too.
Peter.
Tony Mechelynck
> Peter Weilbacher wrote:
>
>> Tony Mechelynck wrote:
>>
>>> :move_profile
>>> echo Move %APPDATA%\.mozilla.org\seamonkey
>>>
>> Is it really called .mozilla.org on Windows at the moment with the
>> leading dot?
>>
>>
> Not on Windows, no... maybe that was a bad port from Linux, where the
> name is lowercased and dot-prefixed.
>
Sorry, my fault. I don't have a M$ box anymore: I was doing it all from
memory. Anything I misunderstood or overlooked should of course be corrected
by anyone who knows better.
Best regards,
Tony.
--
Women who want to be equal to men lack imagination
-- Graffito in a women's restroom
Robert Kaiser
> The script looks OK (except [...]).
How far are we on this issue? I'd like to get that change in ASAP but we
still need some strategy of how we point people to those scripts and
where we put them for being pointed to.
And do we have something for both Linux and Windows?
Robert Kaiser
Andrew Schultz
> To still find the correct profile in profiles.ini, I think one should
> change
> if (/^Name/) {
> split($0,name,"=");
> if (name[2] == profname) {
> found=1; print;
> }
> }
> to
> if (/^Name/) { name=$0; }
> if (/^IsRelative/) { isRel=$0; }
> if (/^Path/) {
> split($0,path,".");
> if (path[2] == profname) {
> found=1;
> print name;
> print isRel;
> print;
> }
Actually, with your profile.ini section and this script, you'd have to
invoke the script with "default" whereas your profile name is "Peter".
If you start seamonkey and specify the profile on the commandline, you
have to use "Peter", right? And the profile shows up in the profile
manager as "Peter"?
Andrew Schultz
> [Profile0]
> Name=Peter
> IsRelative=1
> Path=gmrsva54.default
> Default=1
Ah. You renamed your profile. :)
> As the script uses the actual path of the profile to confirm that the
> profile is there and not yet copied, I think it would make sense to
> use the path to find it in profiles.ini, too.
right. I've attached an updated version that should handle renamed
profiles (but you'd still have to tell it to migrate "Peter" and not
"default").
Andrew Schultz
> How far are we on this issue? I'd like to get that change in ASAP but we
> still need some strategy of how we point people to those scripts and
> where we put them for being pointed to.
I think the latest incarnation of the script should handle just profile
migration on linux.
I had noticed that secmod.db actually contains the profile path (in my
case, the xpfe profile path), but I don't think it would even get used
because PSM initializes NSS with the real profile path:
It looks like one of the first things NSS does it to initialize
secmod.db with that.
> And do we have something for both Linux and Windows?
Linux, yes (assuming Peter doesn't poke more holes in what I posted)
Windows, no (Tony posted something, but it apparently needed work)
Mac, no (should probably be straightforward to get the linux script
working on Mac)
Peter Weilbacher
> Peter Weilbacher wrote:
>> [Profile0]
>> Name=Peter
>> IsRelative=1
>> Path=gmrsva54.default
>> Default=1
>
> Ah. You renamed your profile. :)
Oh right. I didn't remember doing so, but now I tried to migrator again
and so I conclude that I have done that because that tool didn't take
up the names that I had set since the old Mozilla Suite profiles. I never
got around to file a bug about that.
>> As the script uses the actual path of the profile to confirm that the
>> profile is there and not yet copied, I think it would make sense to
>> use the path to find it in profiles.ini, too.
>
> right. I've attached an updated version that should handle renamed
> profiles (but you'd still have to tell it to migrate "Peter" and not
> "default").
Yes, that is what I would expect. It works well now. I would, however,
output
"no profile with the name \"${1}\" found in profiles.ini"
instead of
"failed to parse profiles.ini"
As you alread have an awk test at the top, which I think is already a
bit of overkill, perhaps you should add a perl test, too? If I would
start nitpicking I would say use different values for each exit -- but
as I don't I think the updated version is ready to go with these two
little changes. :-)
Peter.
Robert Kaiser
> Mac, no (should probably be straightforward to get the linux script
> working on Mac)
I repeat: Mac does NOT change the profile location when we change the
vendor ID. We do NOT need a script that works on Mac.
So, it seems to me that we need to get the Windows version up to speed,
and that should be all.
Where should we put those scripts and how should we point people to to them?
Robert Kaiser
Tony Mechelynck
> On Sun, 9 Sep 2007 05:56:45 UTC, Andrew Schultz wrote:
>
>> Windows, no (Tony posted something, but it apparently needed work)
>
> with a way to automatically edit the prefs.js/user.js and extensions.ini
> files. I can't believe that there is no way, but apparently we have not
> enough experienced Windows batch programmers around...
There aren't enough editors with a batch mode packaged with Windows nowadays.
Dos used to have EDLIN (though I don't fully remember what it could and
couldn't do), but is it still included? As I am now Linux-only, I cannot check.
Best regards,
Tony.
--
ARTHUR: You are indeed brave Sir knight, but the fight is mine.
BLACK KNIGHT: Had enough?
ARTHUR: You stupid bastard. You havn't got any arms left.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
Justin Wood (Callek)
My suggestion is to use a Start-Page gecko id sniffer (for now) and
announce it there. Link to them on our area of mozilla.org "Migrating
Tester Nightly Profiles, in reasponse to Bug #" or some such as the
title of the page ;-)
Have a post to the support newsgroup, and mozillazine forums, and post
about the impact to nightly testers on both your blog and the official
seamonkey blog. (imho).
Lastly be sure people on #seamonkey know about it, and are willing to
help anyone who comes in and has a problem (people on #seamonkey should
of course have full details so they can help in the slim chances these
scripts fail)
~Justin Wood (Callek)
Dave Yeo
> Andrew Schultz wrote:
>> Peter Weilbacher wrote:
>>> [Profile0]
>>> Name=Peter
>>> IsRelative=1
>>> Path=gmrsva54.default
>>> Default=1
>>
>> Ah. You renamed your profile. :)
>
> Oh right. I didn't remember doing so, but now I tried to migrator again
> and so I conclude that I have done that because that tool didn't take
> up the names that I had set since the old Mozilla Suite profiles. I never
> got around to file a bug about that.
Don't know if that is your OS/2 profile or Linux profile but my OS/2
profile is
[Profile0]
Name=Dave
IsRelative=1
Path=Profiles/dcs4od50.default
Default=1
And I'm pretty sure I never renamed it. At that I think originally it
was NS4.61 that created the profile with the name dave_yeo (my isp email
login name at the time) and it has been migrated to Mozilla as dave_yeo
and now to Seamonkey as Dave
Dave
Andrew Schultz
> Andrew Schultz wrote:
>> Mac, no (should probably be straightforward to get the linux script
>> working on Mac)
>
> I repeat: Mac does NOT change the profile location when we change the
> vendor ID. We do NOT need a script that works on Mac.
OK. I guess I remember you or someone mentioned that before.
> So, it seems to me that we need to get the Windows version up to speed,
> and that should be all.
>
> Where should we put those scripts and how should we point people to to
> them?
As far as where, I was thinking something along the lines of what Callek
said (everywhere). :) This will all go most smoothly if people don't
discover this by using a new build.
It might also be good to have a short text that describes what someone
would do to manually migrate. I guess we could have a wiki page that
describes what's going on and links to the scripts and we could post
(everywhere) and link to the wiki page.
Robert Kaiser
> Robert Kaiser wrote:
>> Where should we put those scripts and how should we point people to to
>> them?
>
> My suggestion is to use a Start-Page gecko id sniffer (for now) and
> announce it there. Link to them on our area of mozilla.org "Migrating
> Tester Nightly Profiles, in reasponse to Bug #" or some such as the
> title of the page ;-)
Somebody should probably create a wikimo or even MDC page that can be
linked anywhere and has downloadable links for the Linux and Windows
scripts.
The downside probably is that anyone who sees the start page already has
created and launched a new default profile, so it's questionable how
much it helps then.
> Have a post to the support newsgroup, and mozillazine forums, and post
> about the impact to nightly testers on both your blog and the official
> seamonkey blog. (imho).
As if anyone still posts to that so-called "official SeaMonkey blog" :-/
Newsgroups and my blog which appears on planet were in my plan anyways,
mozine forums might be a good idea. Once again, a page to link to would
be nice.
> Lastly be sure people on #seamonkey know about it, and are willing to
> help anyone who comes in and has a problem (people on #seamonkey should
> of course have full details so they can help in the slim chances these
> scripts fail)
Sure, that's the smallest of problems ;-)
Once again, the page to link to would be cool there :)
Robert Kaiser
Robert Kaiser
> It might also be good to have a short text that describes what someone
> would do to manually migrate. I guess we could have a wiki page that
> describes what's going on and links to the scripts and we could post
> (everywhere) and link to the wiki page.
Sounds good. Who will write that up?
Robert Kaiser
Justin Wood (Callek)
> Justin Wood (Callek) wrote:
>> Robert Kaiser wrote:
>>> Where should we put those scripts and how should we point people to
>>> to them?
>>
>> My suggestion is to use a Start-Page gecko id sniffer (for now) and
>> announce it there. Link to them on our area of mozilla.org "Migrating
>> Tester Nightly Profiles, in reasponse to Bug #" or some such as the
>> title of the page ;-)
>
> Somebody should probably create a wikimo or even MDC page that can be
> linked anywhere and has downloadable links for the Linux and Windows
> scripts.
> The downside probably is that anyone who sees the start page already has
> created and launched a new default profile, so it's questionable how
> much it helps then.
>
The downside to NOT doing it on the start page is someone who doesn't
follow newsgroups AND uses a nightly and looses their previous nightly
profile would be in trouble, at least having links and hearing about how
to fix it and where to go for "further" help would alleviate any trouble
they face should they choose (not) to just dump their old profile in the
proverbial trash.
~Justin Wood (Callek)
Peter Weilbacher
Seems that nobody has done so.
If somebody can create a new wiki page (I don't know where that would make
sense) I could try to help to fill it in. But where do(es) the script(s)
go? The wikis still don't allow to upload scripts (bug 351317) as far as
I know.
Peter.
Neil
>The wikis still don't allow to upload scripts (bug 351317) as far as I know.
>
>
One alternative is to prefix each line of the script with a space and
paste it in as a preformatted block.
Robert Kaiser
> If somebody can create a new wiki page (I don't know where that would make
> sense) I could try to help to fill it in.
How about
http://wiki.mozilla.org/SeaMonkey:Moving_Profiles_from_mozilla.org_to_Mozilla
- would that location/title make sense? If you think so, just use the
"edit this page" link there ;-)
> But where do(es) the script(s)
> go? The wikis still don't allow to upload scripts (bug 351317) as far as
> I know.
We can put up the scripts on some place on the SeaMonkey website.
Robert Kaiser
Peter Weilbacher
> I repeat: Mac does NOT change the profile location when we change the
> vendor ID. We do NOT need a script that works on Mac.
So what _is_ the correct location on Mac? Somebody recently corrected
http://wiki.mozilla.org/SeaMonkey:New_for_2.0
and changed the profile location for Mac, too.
Peter.
Peter Weilbacher
> Peter Weilbacher wrote:
>> If somebody can create a new wiki page (I don't know where that would make
>> sense) I could try to help to fill it in.
>
> How about
> http://wiki.mozilla.org/SeaMonkey:Moving_Profiles_from_mozilla.org_to_Mozilla
> - would that location/title make sense? If you think so, just use the
> "edit this page" link there ;-)
Fine with me. I started editing that page. I am doing this quickly, so I hope that
somebody will go there later and correct all the mistakes.
I just made up a location for the Linux script. When that is actually uploaded
somewhere, please correct the URL.
Peter.
Andrew Schultz
> Fine with me. I started editing that page. I am doing this quickly, so I hope that
> somebody will go there later and correct all the mistakes.
Looks good to me. Thanks!
Robert Kaiser
> So what _is_ the correct location on Mac? Somebody recently corrected
> http://wiki.mozilla.org/SeaMonkey:New_for_2.0
> and changed the profile location for Mac, too.
I just edited that page to the correct location, as far as I know, which
is ~/Library/Application Support/SeaMonkey/Profiles/<Profile name>/
Thanks for pointing to this.
Robert Kaiser
George3
has one, the profile location for SM2.0 needs to be corrected here
too:
http://kb.mozillazine.org/Profile_folder_-_SeaMonkey#Default_profile_location
George3
> I'm trying to get an account for the KB Wiki but if someone already
> has one, the profile location for SM2.0 needs to be corrected here
Ok, kb.mozillazine... is updated now.
To summarize, SeaMonkey 2.0's profile location is updated at these
locations:
1) http://wiki.mozilla.org/SeaMonkey:New_for_2.0
2) http://wiki.mozilla.org/SeaMonkey:Moving_Profiles_from_mozilla.org_to_Mozilla
3) http://kb.mozillazine.org/Profile_folder_-_SeaMonkey
Robert Kaiser
> Peter Weilbacher wrote:
>> Fine with me. I started editing that page. I am doing this quickly, so
>> I hope that
>> somebody will go there later and correct all the mistakes.
>
> Looks good to me. Thanks!
Do we have everything in place now that I can check in th actual change?
Robert Kaiser
Peter Weilbacher
> Do we have everything in place now that I can check in th actual change?
Seems like nobody uploaded Andrew's script yet to the SeaMonkey webspace.
P.
Robert Kaiser
> Seems like nobody uploaded Andrew's script yet to the SeaMonkey webspace.
OK, I uploaded it to a better location on the new site actually and
adjusted the link on the wiki.
So, are we happy with leaving Windows users with a manual move?
If so, I'll go forward and do the checkin in the next few days.
Robert Kaiser
Justin Wood (Callek)
Personally, yes I'm happy with windows users having a manual move.
Mainly because I can't think of any *good* way to write a script to do
it for windows users, unless we write a .exe to do it, and that would be
overkill for my personal willingness to work on this.
~Justin Wood (Callek)
Robert Kaiser
> Personally, yes I'm happy with windows users having a manual move.
>
> Mainly because I can't think of any *good* way to write a script to do
> it for windows users, unless we write a .exe to do it, and that would be
> overkill for my personal willingness to work on this.
OK, will do the checkin then...
Robert Kaiser