Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
test build2
39 views
Skip to first unread message
Dave Yeo
Apr 30, 2012, 10:14:04 AM4/30/12
to
I've uploaded another test build,
firefox-10.0.4.preview.2.en-US.os2.zip. Hopefully the focus issue is
fixed, printing is working and perhaps the RMB crash is fixed.
Dave
firefox-10.0.4.preview.2.en-US.os2.zip. Hopefully the focus issue is
fixed, printing is working and perhaps the RMB crash is fixed.
Dave
Dave Saville
Apr 30, 2012, 11:51:51 AM4/30/12
to
On Mon, 30 Apr 2012 14:14:04 UTC, Dave Yeo <dave....@gmail.com>
wrote:
> I've uploaded another test build,
> firefox-10.0.4.preview.2.en-US.os2.zip. Hopefully the focus issue is
> fixed, printing is working and perhaps the RMB crash is fixed.
>
Thanks Dave, Good news and bad news:
Printing works :-)
RMB crash is still there :-(
Yet to see if focus issues all gone.
--
Regards
Dave Saville
wrote:
> I've uploaded another test build,
> firefox-10.0.4.preview.2.en-US.os2.zip. Hopefully the focus issue is
> fixed, printing is working and perhaps the RMB crash is fixed.
>
Printing works :-)
RMB crash is still there :-(
Yet to see if focus issues all gone.
--
Regards
Dave Saville
David McKenna
Apr 30, 2012, 12:01:26 PM4/30/12
to dev-po...@lists.mozilla.org
Dave,
Thanks... focus seems good, and printing works. I've never seen the RMB
crash issue. One thing about this test build is I can't get any plugin to
work... FF just hangs when I try and must be killed.
Dave McKenna
crash issue. One thing about this test build is I can't get any plugin to
work... FF just hangs when I try and must be killed.
Dave McKenna
Steven Levine
Apr 30, 2012, 4:17:34 PM4/30/12
to
Hi Dave,
> I've uploaded another test build,
> firefox-10.0.4.preview.2.en-US.os2.zip. Hopefully the focus issue is
> fixed, printing is working and perhaps the RMB crash is fixed.
Which gcc did you build this with?
Steven
--
---------------------------------------------------------------------
Steven Levine <ste...@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com
---------------------------------------------------------------------
> I've uploaded another test build,
> firefox-10.0.4.preview.2.en-US.os2.zip. Hopefully the focus issue is
> fixed, printing is working and perhaps the RMB crash is fixed.
Steven
--
---------------------------------------------------------------------
Steven Levine <ste...@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com
---------------------------------------------------------------------
Dave Yeo
Apr 30, 2012, 6:35:42 PM4/30/12
to
Steven Levine wrote:
> On Mon, 30 Apr 2012 14:14:04 UTC, Dave Yeo<dave....@gmail.com>
> wrote:
>
> Hi Dave,
>
>> > I've uploaded another test build,
>> > firefox-10.0.4.preview.2.en-US.os2.zip. Hopefully the focus issue is
>> > fixed, printing is working and perhaps the RMB crash is fixed.
> Which gcc did you build this with?
GCC 4.4.1 as usual. about:buildconfig will report the build environment,
> On Mon, 30 Apr 2012 14:14:04 UTC, Dave Yeo<dave....@gmail.com>
> wrote:
>
> Hi Dave,
>
>> > I've uploaded another test build,
>> > firefox-10.0.4.preview.2.en-US.os2.zip. Hopefully the focus issue is
>> > fixed, printing is working and perhaps the RMB crash is fixed.
> Which gcc did you build this with?
about:support reports other stuff.
Dave
Dave Yeo
Apr 30, 2012, 6:38:47 PM4/30/12
to
awget, then hangs with 100% CPU. Weird.
Dave
kbr_n...@guzzi.demon.nospam.nl
Apr 30, 2012, 6:52:03 PM4/30/12
to
In <7MSdnS5_8rEdiQLS...@mozilla.org>, on 04/30/12
partly , then stop loading, FF freezes with about 50% load on one cpu.
Reverted to the first test build.
The first testbuild caused freezes when closing FF after it had been up
for a longer than a few hours. Have seen this before with some older
version, cured it by raising virtualaddresslimit from 1260 to 1536.
Btw, there is a beta version of a new ini cleaner on the betazone by none
other than Rich Walsh....
Cheers, Bjorn.
--
-----------------------------------------------------------
k...@guzzi.demon.nl
-----------------------------------------------------------
at 03:38 PM, Dave Yeo <dave....@gmail.com> said:
>You're right, though quickly testing with the awget plugin, it does call
>awget, then hangs with 100% CPU. Weird.
Here it works using several plugins for some sites but others will load
>You're right, though quickly testing with the awget plugin, it does call
>awget, then hangs with 100% CPU. Weird.
partly , then stop loading, FF freezes with about 50% load on one cpu.
Reverted to the first test build.
The first testbuild caused freezes when closing FF after it had been up
for a longer than a few hours. Have seen this before with some older
version, cured it by raising virtualaddresslimit from 1260 to 1536.
Btw, there is a beta version of a new ini cleaner on the betazone by none
other than Rich Walsh....
Cheers, Bjorn.
--
-----------------------------------------------------------
k...@guzzi.demon.nl
-----------------------------------------------------------
Steven Levine
Apr 30, 2012, 7:21:39 PM4/30/12
to
On Mon, 30 Apr 2012 22:35:42 UTC, Dave Yeo <dave....@gmail.com>
wrote:
Hi Dave,
> >> > firefox-10.0.4.preview.2.en-US.os2.zip. Hopefully the focus issue is
> >> > fixed, printing is working and perhaps the RMB crash is fixed.
> > Which gcc did you build this with?
> GCC 4.4.1 as usual. about:buildconfig will report the build environment,
> about:support reports other stuff.
And which gcc3.3.5 are you using that back this up? It appears that
you are using csd5. Is this the case?
wrote:
Hi Dave,
> >> > firefox-10.0.4.preview.2.en-US.os2.zip. Hopefully the focus issue is
> >> > fixed, printing is working and perhaps the RMB crash is fixed.
> > Which gcc did you build this with?
> GCC 4.4.1 as usual. about:buildconfig will report the build environment,
> about:support reports other stuff.
you are using csd5. Is this the case?
Dave Yeo
Apr 30, 2012, 9:53:15 PM4/30/12
to
Steven Levine wrote:
> On Mon, 30 Apr 2012 22:35:42 UTC, Dave Yeo<dave....@gmail.com>
> wrote:
>
> Hi Dave,
>
>>>>> firefox-10.0.4.preview.2.en-US.os2.zip. Hopefully the focus issue is
>>>>> fixed, printing is working and perhaps the RMB crash is fixed.
>>> Which gcc did you build this with?
>
>> GCC 4.4.1 as usual. about:buildconfig will report the build environment,
>> about:support reports other stuff.
>
> And which gcc3.3.5 are you using that back this up? It appears that
> you are using csd5. Is this the case?
>
Yes.
> On Mon, 30 Apr 2012 22:35:42 UTC, Dave Yeo<dave....@gmail.com>
> wrote:
>
> Hi Dave,
>
>>>>> firefox-10.0.4.preview.2.en-US.os2.zip. Hopefully the focus issue is
>>>>> fixed, printing is working and perhaps the RMB crash is fixed.
>>> Which gcc did you build this with?
>
>> GCC 4.4.1 as usual. about:buildconfig will report the build environment,
>> about:support reports other stuff.
>
> And which gcc3.3.5 are you using that back this up? It appears that
> you are using csd5. Is this the case?
>
Dave
Steven Levine
Apr 30, 2012, 11:18:37 PM4/30/12
to
On Tue, 1 May 2012 01:53:15 UTC, Dave Yeo <dave....@gmail.com>
wrote:
Hi Dave,
OK. That's what I suspected.
If you want to suppress the new style arg logic what you can do is
backlevel the os2stub.bin that exists in the directory that contains
emxomfld.exe. If you build the Mozilla apps with the original
os2stub.bin, libc064/libc065 will not attempt to apply the new unix
args logic.
Another option is to binary edit the stub before zipping up the
distro.
The stub that triggers the special case arg logic contains
v0.6.4+
Blanking this out will turn off the special case logic.
wrote:
Hi Dave,
OK. That's what I suspected.
If you want to suppress the new style arg logic what you can do is
backlevel the os2stub.bin that exists in the directory that contains
emxomfld.exe. If you build the Mozilla apps with the original
os2stub.bin, libc064/libc065 will not attempt to apply the new unix
args logic.
Another option is to binary edit the stub before zipping up the
distro.
The stub that triggers the special case arg logic contains
v0.6.4+
Blanking this out will turn off the special case logic.
Dave Yeo
May 1, 2012, 12:06:58 AM5/1/12
to
Steven Levine wrote:
> On Tue, 1 May 2012 01:53:15 UTC, Dave Yeo<dave....@gmail.com>
> wrote:
>
> Hi Dave,
>
> OK. That's what I suspected.
>
> If you want to suppress the new style arg logic what you can do is
> backlevel the os2stub.bin that exists in the directory that contains
> emxomfld.exe. If you build the Mozilla apps with the original
> os2stub.bin, libc064/libc065 will not attempt to apply the new unix
> args logic.
>
> Another option is to binary edit the stub before zipping up the
> distro.
>
> The stub that triggers the special case arg logic contains
>
> v0.6.4+
>
> Blanking this out will turn off the special case logic.
>
Yes, swapping the os2stub.bin sounds the simplest, much better then
> On Tue, 1 May 2012 01:53:15 UTC, Dave Yeo<dave....@gmail.com>
> wrote:
>
> Hi Dave,
>
> OK. That's what I suspected.
>
> If you want to suppress the new style arg logic what you can do is
> backlevel the os2stub.bin that exists in the directory that contains
> emxomfld.exe. If you build the Mozilla apps with the original
> os2stub.bin, libc064/libc065 will not attempt to apply the new unix
> args logic.
>
> Another option is to binary edit the stub before zipping up the
> distro.
>
> The stub that triggers the special case arg logic contains
>
> v0.6.4+
>
> Blanking this out will turn off the special case logic.
>
binary editing the binary.
Thanks
Dave
Mark Dodel
May 1, 2012, 12:35:47 PM5/1/12
to
On Mon, 30 Apr 2012 16:01:26 UTC, "David McKenna"
<davidm...@comcast.net> wrote:
-> Dave,
->
-> On Mon, 30 Apr 2012 07:14:04 -0700, Dave Yeo wrote:
->
-> >I've uploaded another test build,
-> >firefox-10.0.4.preview.2.en-US.os2.zip. Hopefully the focus issue is
-> >fixed, printing is working and perhaps the RMB crash is fixed.
-> >Dave
->
-> Thanks... focus seems good, and printing works. I've never seen the RMB
-> crash issue. One thing about this test build is I can't get any plugin to
-> work... FF just hangs when I try and must be killed.
->
I think I am seeing the same here by going to
http://www.google.com/finance?q=NASDAQ:AAPL which uses Flash (though
I have Flash Block, at least I think I did). Have to use C-Alt-Del to
kill it.
Mark
--
From the eComStation 2.1 GA desktop of Mark Dodel
Warpstock 2011 - http://www.warpstock.org
Warpstock Europe 2011 - http://www.warpstock.eu
<davidm...@comcast.net> wrote:
-> Dave,
->
-> On Mon, 30 Apr 2012 07:14:04 -0700, Dave Yeo wrote:
->
-> >I've uploaded another test build,
-> >firefox-10.0.4.preview.2.en-US.os2.zip. Hopefully the focus issue is
-> >fixed, printing is working and perhaps the RMB crash is fixed.
-> >Dave
->
-> Thanks... focus seems good, and printing works. I've never seen the RMB
-> crash issue. One thing about this test build is I can't get any plugin to
-> work... FF just hangs when I try and must be killed.
->
I think I am seeing the same here by going to
http://www.google.com/finance?q=NASDAQ:AAPL which uses Flash (though
I have Flash Block, at least I think I did). Have to use C-Alt-Del to
kill it.
Mark
--
From the eComStation 2.1 GA desktop of Mark Dodel
Warpstock 2011 - http://www.warpstock.org
Warpstock Europe 2011 - http://www.warpstock.eu
Dave Yeo
May 1, 2012, 9:45:26 PM5/1/12
to
Mark Dodel wrote:
> On Mon, 30 Apr 2012 16:01:26 UTC, "David McKenna"
> <davidm...@comcast.net> wrote:
>
> -> Dave,
> ->
> -> On Mon, 30 Apr 2012 07:14:04 -0700, Dave Yeo wrote:
> ->
> -> >I've uploaded another test build,
> -> >firefox-10.0.4.preview.2.en-US.os2.zip. Hopefully the focus issue is
> -> >fixed, printing is working and perhaps the RMB crash is fixed.
> -> >Dave
> ->
> -> Thanks... focus seems good, and printing works. I've never seen the RMB
> -> crash issue. One thing about this test build is I can't get any plugin to
> -> work... FF just hangs when I try and must be killed.
> ->
>
> I think I am seeing the same here by going to
> http://www.google.com/finance?q=NASDAQ:AAPL which uses Flash (though
> I have Flash Block, at least I think I did). Have to use C-Alt-Del to
> kill it.
>
I found Rich's fix for this issue and locally plugins are once again
> On Mon, 30 Apr 2012 16:01:26 UTC, "David McKenna"
> <davidm...@comcast.net> wrote:
>
> -> Dave,
> ->
> -> On Mon, 30 Apr 2012 07:14:04 -0700, Dave Yeo wrote:
> ->
> -> >I've uploaded another test build,
> -> >firefox-10.0.4.preview.2.en-US.os2.zip. Hopefully the focus issue is
> -> >fixed, printing is working and perhaps the RMB crash is fixed.
> -> >Dave
> ->
> -> Thanks... focus seems good, and printing works. I've never seen the RMB
> -> crash issue. One thing about this test build is I can't get any plugin to
> -> work... FF just hangs when I try and must be killed.
> ->
>
> I think I am seeing the same here by going to
> http://www.google.com/finance?q=NASDAQ:AAPL which uses Flash (though
> I have Flash Block, at least I think I did). Have to use C-Alt-Del to
> kill it.
>
working.
The focus issue was caused by a patch that Rich wrote and affected the
first drop of FF6. The patch was backed out and FF6 was released before
anyone noticed but it seems that Walter never removed it from his tree.
Originally it affected the focus after printing but seems to have got
worse :) I've had to revert to a couple of earlier patches that also
fixed the same issues, the plugin looping due to duplicate windows and
the crash in pmmerge when posting a message in SM and TB.
I have to backout my attempt to fix the RMB crash as it doesn't seem to
have helped Dave, rebuild and upload another, hopefully the last test
build. The I'll upload the other apps.
Dave
Steve Wendt
May 1, 2012, 10:09:24 PM5/1/12
to
On 5/1/2012 6:45 PM, Dave Yeo wrote:
> The focus issue was caused by a patch that Rich wrote and affected the
> first drop of FF6. The patch was backed out and FF6 was released before
> anyone noticed but it seems that Walter never removed it from his tree.
> Originally it affected the focus after printing but seems to have got
> worse :) I've had to revert to a couple of earlier patches that also
> fixed the same issues, the plugin looping due to duplicate windows and
> the crash in pmmerge when posting a message in SM and TB.
This is why source code version control repositories exist. :-)
> The focus issue was caused by a patch that Rich wrote and affected the
> first drop of FF6. The patch was backed out and FF6 was released before
> anyone noticed but it seems that Walter never removed it from his tree.
> Originally it affected the focus after printing but seems to have got
> worse :) I've had to revert to a couple of earlier patches that also
> fixed the same issues, the plugin looping due to duplicate windows and
> the crash in pmmerge when posting a message in SM and TB.
Dave Yeo
May 2, 2012, 12:10:20 AM5/2/12
to
spending 2 hours all I can get is
https://bitbucket.org/dryeo/os2_mozilla_patches/overview. Using the fine
manual, this should contain all my patches but doesn't, just the series
and .hgignore. There is a good chance our Mercurial port is incomplete :(
Dave
Dave Yeo
May 2, 2012, 12:48:42 AM5/2/12
to
Dave Yeo wrote:
> I've had to revert to a couple of earlier patches that also fixed the
> same issues, the plugin looping due to duplicate windows
I meant duplicate children.
> I've had to revert to a couple of earlier patches that also fixed the
> same issues, the plugin looping due to duplicate windows
Dave
Lewis Rosenthal
May 2, 2012, 8:45:37 PM5/2/12
to
Hey, guys...
On 04/30/12 06:52 pm, kbr_n...@guzzi.demon.nospam.nl thus wrote :
while), as I found that none of my Astaro firewalls would get to the
login page for me (or rather, I could not get to the login page on any
of them). I got a stall at about 80% of the page load (if the progress
bar can be believed), which required killing the app. The login pages
use self-signed certs on non-standard ports, though I'm not sure if that
would have been the trigger or not. The previous test build seems to not
suffer from this.
> The first testbuild caused freezes when closing FF after it had been up
> for a longer than a few hours. Have seen this before with some older
> version, cured it by raising virtualaddresslimit from 1260 to 1536.
>
Didn't try this one, as I only had it up and running for a few minutes
on the test system. But as I've rarely been able to run any system with
VIRTUALADDRESSLIMIT down as low as 1260, I doubt that I'd see the same
symptom.
> Btw, there is a beta version of a new ini cleaner on the betazone by none
> other than Rich Walsh....
>
Are you talking about DMT (Desktop Maintenance Tool)? We've had a bit of
a discussion of that on eCS-Technical, recently.
Cheers/2
--
Lewis
-------------------------------------------------------------
Lewis G Rosenthal, CNA, CLP, CLE, CWTS
Rosenthal & Rosenthal, LLC www.2rosenthals.com
Need a managed Wi-Fi hotspot? www.hautspot.com
visit my IT blog www.2rosenthals.net/wordpress
-------------------------------------------------------------
On 04/30/12 06:52 pm, kbr_n...@guzzi.demon.nospam.nl thus wrote :
> In<7MSdnS5_8rEdiQLS...@mozilla.org>, on 04/30/12
> at 03:38 PM, Dave Yeo<dave....@gmail.com> said:
>
>
>> You're right, though quickly testing with the awget plugin, it does call
>> awget, then hangs with 100% CPU. Weird.
>
> Here it works using several plugins for some sites but others will load
> partly , then stop loading, FF freezes with about 50% load on one cpu.
> Reverted to the first test build.
>
Thanks, Bjorn. I was going to post this here (hadn't been on in a little
> at 03:38 PM, Dave Yeo<dave....@gmail.com> said:
>
>
>> You're right, though quickly testing with the awget plugin, it does call
>> awget, then hangs with 100% CPU. Weird.
>
> Here it works using several plugins for some sites but others will load
> partly , then stop loading, FF freezes with about 50% load on one cpu.
> Reverted to the first test build.
>
while), as I found that none of my Astaro firewalls would get to the
login page for me (or rather, I could not get to the login page on any
of them). I got a stall at about 80% of the page load (if the progress
bar can be believed), which required killing the app. The login pages
use self-signed certs on non-standard ports, though I'm not sure if that
would have been the trigger or not. The previous test build seems to not
suffer from this.
> The first testbuild caused freezes when closing FF after it had been up
> for a longer than a few hours. Have seen this before with some older
> version, cured it by raising virtualaddresslimit from 1260 to 1536.
>
on the test system. But as I've rarely been able to run any system with
VIRTUALADDRESSLIMIT down as low as 1260, I doubt that I'd see the same
symptom.
> Btw, there is a beta version of a new ini cleaner on the betazone by none
> other than Rich Walsh....
>
a discussion of that on eCS-Technical, recently.
Cheers/2
--
Lewis
-------------------------------------------------------------
Lewis G Rosenthal, CNA, CLP, CLE, CWTS
Rosenthal & Rosenthal, LLC www.2rosenthals.com
Need a managed Wi-Fi hotspot? www.hautspot.com
visit my IT blog www.2rosenthals.net/wordpress
-------------------------------------------------------------
Dave Yeo
May 2, 2012, 10:39:03 PM5/2/12
to dev-po...@lists.mozilla.org
On 05/02/12 05:45 pm, Lewis Rosenthal wrote:
> We've had a bit of a discussion of that on eCS-Technical,
Where is eCS-Technical?
> We've had a bit of a discussion of that on eCS-Technical,
Dave
Felix Miata
May 3, 2012, 4:29:58 AM5/3/12
to
On 2012/05/02 19:39 (GMT-0700) Dave Yeo composed:
> Where is eCS-Technical?
eCS-Te...@yahoogroups.com
> Where is eCS-Technical?
eCS-Te...@yahoogroups.com
David Arturo Macias Corona
May 3, 2012, 5:44:24 AM5/3/12
to
Ignore
Iam testing how to send messages to newsgroup
Iam testing how to send messages to newsgroup
David Arturo Macias Corona
May 3, 2012, 5:46:53 AM5/3/12
to
Maybe this is a "well known" problem, but not for me
If somebody knows solution(s) please re-direct me
I have a lot of years using Mozilla and later Seamonkey on OS/2
Currently:
- eCS 2.0
- Build identifier: Mozilla/5.0 (OS/2; Warp 4.5; rv:10.0.2)
Gecko/20120216 Firefox/10.0.2 SeaMonkey/2.7
When I jumped from Seamonkey 1.1.19 to 2.x series, a lot of problems raised
I installed a long time ago Seamonkey 2.0 and Samba server with two days
difference, so problems from each one appeared mixed
At closing eCS it hang at "releasing filesystems", then I found it is
caused by Samba server, so I start it manually when I need and that
problem disappear
For Seamonkey, I share main profile with SM-OS/2 and SM-Windows on a
FAT32 partition/directory, but I use SM-Windows rarely
Even if I do not use SM-Windows, SM-OS/2 files appear damaged/corrupted
very often, with problem of any kind
Most of times are problems with sessionstore*.json files ( CHKDSK on
Windows find them corrupted ), but other times are another files
Most recent problem was places.sqlite-wal file
Below is a list of some sessionstore*.json files, which are a mix of
good and corrupted files
Corrupted files refused to copy using XCOPY or COPY
SM-OS/2 are creating those files increasing numbering, and some of them
are corrupted. Time ago it was around 80 files, and I deleted them from
time to time
Some weeks ago SM-OS/2 was too slow, and I found around 6 files with
around 500 Mbytes file size with different numbering. After deleting
them SM-OS/2 was near "fine" ago
Usual file size is around 3 Mb, but not 500 Mb
When problem happen most of time is Seamonkey blank screen, missing
opened tabs
Then I start to copy from my Seamonkey backups one file at a time, until
everything is restored
Based on this, I know corrupted case is in any file
I have checked with profiles, now I have five
- Main profile, on FAT32
- 2,3,4,5 profiles, on HPFS
Only profile on FAT32 show this problem, so I conclude it as an problem
between SM-OS/2 and FAT32 partition/driver
Only happen in SM 2.x series, and does not happen in SM 1.x series
Due this problem, I try not to use main profile, but it manage my Mail :-(
and I want to mantain as is, on FAT32, to access from Windows when I need it
And I do not want to change to FF-Thunderbird
I try to have fixed this problem with SM-OS2-FAT32
How often this problem happen ? Randomly
It may crash two or three times on a day, or crash two or three days in
between
But failure will happen for sure
If somebody want to try, just create an SM 2.x profile on FAT32
partition and use it heavily some days with 3 to 7 tabs
Somebody knows about this problem and their solutions ?
David Macias
18/12/11 7:38a 3,793,594 0 a--- sessionstore-2.json
22/12/11 5:28a 0 0 a--- sessionstore-4.json
22/12/11 7:23a 18,169,856 0 a--- sessionstore-3.json
12/01/12 7:16p 2,657,927 0 a--- sessionstore-11.json
17/01/12 6:44a 1,867,776 0 a--- sessionstore-15.json
17/01/12 7:01a 2,668,617 0 a--- sessionstore-16.json
18/01/12 9:10a 10,993,664 0 a--- sessionstore-17.json
14/02/12 7:33p 16,384 0 a--- sessionstore-24.json
23/02/12 7:30a 18,464,768 0 a--- sessionstore-27.json
23/02/12 7:30a 3,588,096 0 a--- sessionstore-28.json
18/04/12 7:01a 688,128 0 a--- sessionstore-5.json
19/04/12 8:00a 2,360,449 0 a--- sessionstore.bak
19/04/12 8:00a 2,360,449 0 a--- sessionstore-19.json
20/04/12 4:13a 2,351,014 0 a--- sessionstore.json
This is result of last repair with Windows CHKDSK
All damaged files were found in SM / FAT32 directory profile:
The volume label in drive D is WINXPP.
The Volume Serial Number is 496F:DD6D.
Directory of D:\found.001
3/05/12 3:16a <DIR> 0 ---- .
3/05/12 3:16a <DIR> 0 ---- ..
3/05/12 3:16a 3,424,256 0 ---- FILE0000.CHK
3/05/12 3:16a 3,407,872 0 ---- FILE0001.CHK
3/05/12 3:16a 3,407,872 0 ---- FILE0002.CHK
3/05/12 3:16a 114,688 0 ---- FILE0003.CHK
3/05/12 3:16a 1,015,808 0 ---- FILE0004.CHK
3/05/12 3:16a 1,884,160 0 ---- FILE0005.CHK
3/05/12 3:16a 606,208 0 ---- FILE0006.CHK
3/05/12 3:16a 98,304 0 ---- FILE0007.CHK
3/05/12 3:16a 1,441,792 0 ---- FILE0008.CHK
3/05/12 3:16a 2,048,000 0 ---- FILE0009.CHK
3/05/12 3:16a 16,384 0 ---- FILE0010.CHK
3/05/12 3:16a 49,152 0 ---- FILE0011.CHK
3/05/12 3:16a 1,687,552 0 ---- FILE0012.CHK
3/05/12 3:16a 16,384 0 ---- FILE0013.CHK
3/05/12 3:16a 376,832 0 ---- FILE0014.CHK
3/05/12 3:16a 983,040 0 ---- FILE0015.CHK
3/05/12 3:16a 1,081,344 0 ---- FILE0016.CHK
3/05/12 3:16a 1,622,016 0 ---- FILE0017.CHK
3/05/12 3:16a 2,981,888 0 ---- FILE0018.CHK
3/05/12 3:16a 2,981,888 0 ---- FILE0019.CHK
3/05/12 3:16a 2,981,888 0 ---- FILE0020.CHK
23 file(s) 32,227,328 bytes used
14,594,785 K bytes free
If somebody knows solution(s) please re-direct me
I have a lot of years using Mozilla and later Seamonkey on OS/2
Currently:
- eCS 2.0
- Build identifier: Mozilla/5.0 (OS/2; Warp 4.5; rv:10.0.2)
Gecko/20120216 Firefox/10.0.2 SeaMonkey/2.7
When I jumped from Seamonkey 1.1.19 to 2.x series, a lot of problems raised
I installed a long time ago Seamonkey 2.0 and Samba server with two days
difference, so problems from each one appeared mixed
At closing eCS it hang at "releasing filesystems", then I found it is
caused by Samba server, so I start it manually when I need and that
problem disappear
For Seamonkey, I share main profile with SM-OS/2 and SM-Windows on a
FAT32 partition/directory, but I use SM-Windows rarely
Even if I do not use SM-Windows, SM-OS/2 files appear damaged/corrupted
very often, with problem of any kind
Most of times are problems with sessionstore*.json files ( CHKDSK on
Windows find them corrupted ), but other times are another files
Most recent problem was places.sqlite-wal file
Below is a list of some sessionstore*.json files, which are a mix of
good and corrupted files
Corrupted files refused to copy using XCOPY or COPY
SM-OS/2 are creating those files increasing numbering, and some of them
are corrupted. Time ago it was around 80 files, and I deleted them from
time to time
Some weeks ago SM-OS/2 was too slow, and I found around 6 files with
around 500 Mbytes file size with different numbering. After deleting
them SM-OS/2 was near "fine" ago
Usual file size is around 3 Mb, but not 500 Mb
When problem happen most of time is Seamonkey blank screen, missing
opened tabs
Then I start to copy from my Seamonkey backups one file at a time, until
everything is restored
Based on this, I know corrupted case is in any file
I have checked with profiles, now I have five
- Main profile, on FAT32
- 2,3,4,5 profiles, on HPFS
Only profile on FAT32 show this problem, so I conclude it as an problem
between SM-OS/2 and FAT32 partition/driver
Only happen in SM 2.x series, and does not happen in SM 1.x series
Due this problem, I try not to use main profile, but it manage my Mail :-(
and I want to mantain as is, on FAT32, to access from Windows when I need it
And I do not want to change to FF-Thunderbird
I try to have fixed this problem with SM-OS2-FAT32
How often this problem happen ? Randomly
It may crash two or three times on a day, or crash two or three days in
between
But failure will happen for sure
If somebody want to try, just create an SM 2.x profile on FAT32
partition and use it heavily some days with 3 to 7 tabs
Somebody knows about this problem and their solutions ?
David Macias
18/12/11 7:38a 3,793,594 0 a--- sessionstore-2.json
22/12/11 5:28a 0 0 a--- sessionstore-4.json
22/12/11 7:23a 18,169,856 0 a--- sessionstore-3.json
12/01/12 7:16p 2,657,927 0 a--- sessionstore-11.json
17/01/12 6:44a 1,867,776 0 a--- sessionstore-15.json
17/01/12 7:01a 2,668,617 0 a--- sessionstore-16.json
18/01/12 9:10a 10,993,664 0 a--- sessionstore-17.json
14/02/12 7:33p 16,384 0 a--- sessionstore-24.json
23/02/12 7:30a 18,464,768 0 a--- sessionstore-27.json
23/02/12 7:30a 3,588,096 0 a--- sessionstore-28.json
18/04/12 7:01a 688,128 0 a--- sessionstore-5.json
19/04/12 8:00a 2,360,449 0 a--- sessionstore.bak
19/04/12 8:00a 2,360,449 0 a--- sessionstore-19.json
20/04/12 4:13a 2,351,014 0 a--- sessionstore.json
This is result of last repair with Windows CHKDSK
All damaged files were found in SM / FAT32 directory profile:
The volume label in drive D is WINXPP.
The Volume Serial Number is 496F:DD6D.
Directory of D:\found.001
3/05/12 3:16a <DIR> 0 ---- .
3/05/12 3:16a <DIR> 0 ---- ..
3/05/12 3:16a 3,424,256 0 ---- FILE0000.CHK
3/05/12 3:16a 3,407,872 0 ---- FILE0001.CHK
3/05/12 3:16a 3,407,872 0 ---- FILE0002.CHK
3/05/12 3:16a 114,688 0 ---- FILE0003.CHK
3/05/12 3:16a 1,015,808 0 ---- FILE0004.CHK
3/05/12 3:16a 1,884,160 0 ---- FILE0005.CHK
3/05/12 3:16a 606,208 0 ---- FILE0006.CHK
3/05/12 3:16a 98,304 0 ---- FILE0007.CHK
3/05/12 3:16a 1,441,792 0 ---- FILE0008.CHK
3/05/12 3:16a 2,048,000 0 ---- FILE0009.CHK
3/05/12 3:16a 16,384 0 ---- FILE0010.CHK
3/05/12 3:16a 49,152 0 ---- FILE0011.CHK
3/05/12 3:16a 1,687,552 0 ---- FILE0012.CHK
3/05/12 3:16a 16,384 0 ---- FILE0013.CHK
3/05/12 3:16a 376,832 0 ---- FILE0014.CHK
3/05/12 3:16a 983,040 0 ---- FILE0015.CHK
3/05/12 3:16a 1,081,344 0 ---- FILE0016.CHK
3/05/12 3:16a 1,622,016 0 ---- FILE0017.CHK
3/05/12 3:16a 2,981,888 0 ---- FILE0018.CHK
3/05/12 3:16a 2,981,888 0 ---- FILE0019.CHK
3/05/12 3:16a 2,981,888 0 ---- FILE0020.CHK
23 file(s) 32,227,328 bytes used
14,594,785 K bytes free
David Arturo Macias Corona
May 3, 2012, 6:02:58 AM5/3/12
to
Sorry for duplicate
I am moving from "test build2" message to own message
Please check message below
David Macias
I am moving from "test build2" message to own message
Please check message below
David Macias
Lewis Rosenthal
May 3, 2012, 9:13:04 AM5/3/12
to
Good morning, David!
On 05/03/12 06:02 am, David Arturo Macias Corona thus wrote :
issues, though recent builds have come a long way since 2.0. That said,
2.7 is probably not as solid as 2.6 (on OS/2, at least).
> I installed a long time ago Seamonkey 2.0 and Samba server with two days
> difference, so problems from each one appeared mixed
> At closing eCS it hang at "releasing filesystems", then I found it is
> caused by Samba server, so I start it manually when I need and that
> problem disappear
>
If this is still an issue with the latest Samba, then you should open a
ticket about it. I stopped using Samba server on my eCS 1.2 web server
some time ago, in an effort to just trim down things which were not in
daily use but taking up resources. I do all of my remote file transfers
to and from that box via FTP, now.
> For Seamonkey, I share main profile with SM-OS/2 and SM-Windows on a
> FAT32 partition/directory, but I use SM-Windows rarely
> Even if I do not use SM-Windows, SM-OS/2 files appear damaged/corrupted
> very often, with problem of any kind
>
What version of the FAT32 IFS are you using? Is CACHEF32 enabled?
> Most of times are problems with sessionstore*.json files ( CHKDSK on
> Windows find them corrupted ), but other times are another files
> Most recent problem was places.sqlite-wal file
>
In my experience, 99% of the time, corruption in FAT32 files under eCS
has been due to lazywriting and timing issues. Disable CACHEF32's
lazywrite with the /L:OFF or completely REM the call to CACHEF32.EXE in
CONFIG.SYS & reboot.
> Below is a list of some sessionstore*.json files, which are a mix of
> good and corrupted files
> Corrupted files refused to copy using XCOPY or COPY
> SM-OS/2 are creating those files increasing numbering, and some of them
> are corrupted. Time ago it was around 80 files, and I deleted them from
> time to time
> Some weeks ago SM-OS/2 was too slow, and I found around 6 files with
> around 500 Mbytes file size with different numbering. After deleting
> them SM-OS/2 was near "fine" ago
> Usual file size is around 3 Mb, but not 500 Mb
>
Sounds like caching to me, and caching on *any* database file can have
disastrous consequences. The best of all worlds would be to keep your
profile on a JFS partition and then using the NTFS NetDrive plugin to
mount an NTFS partition, just have a script rsync your profile from the
JFS volume to the NTFS volume. Remember that under the *best*
circumstances, FAT32 is a risky proposition. As Felix recently wrote on
another forum, in a thread related to FAT32-Ext/ExFAT32and which are
words to live by, "lowest possible robustness."
Both JFS and NTFS are journaling filesystems, making them infinitely
better suited to maintaining transaction-oriented data (database files)
than *any* FAT variant.
> When problem happen most of time is Seamonkey blank screen, missing
> opened tabs
> Then I start to copy from my Seamonkey backups one file at a time, until
> everything is restored
> Based on this, I know corrupted case is in any file
>
> I have checked with profiles, now I have five
> - Main profile, on FAT32
> - 2,3,4,5 profiles, on HPFS
>
> Only profile on FAT32 show this problem, so I conclude it as an problem
> between SM-OS/2 and FAT32 partition/driver
>
> Only happen in SM 2.x series, and does not happen in SM 1.x series
>
> Due this problem, I try not to use main profile, but it manage my Mail :-(
> and I want to mantain as is, on FAT32, to access from Windows when I
> need it
> And I do not want to change to FF-Thunderbird
> I try to have fixed this problem with SM-OS2-FAT32
>
Changing to Tbird won't address the underlying issue. We could just as
easily be having the same conversation about MySQL database files as we
are concerning sqlite database files. The problem is the filesystem and
what you are trying to do with it. The fact that the problem is more
likely to appear using the FAT32 IFS under OS/2 is immaterial, as FAT32
even on Windows would be vulnerable to corruption.
> How often this problem happen ? Randomly
> It may crash two or three times on a day, or crash two or three days in
> between
>
> If somebody want to try, just create an SM 2.x profile on FAT32
> partition and use it heavily some days with 3 to 7 tabs
>
No, thank you. I prefer to keep my real data on real filesystems, and
use FAT32 for storage and shuttling *static* files between different
disconnected systems. ;-)
> Somebody knows about this problem and their solutions ?
>
See above...
> This is result of last repair with Windows CHKDSK
> All damaged files were found in SM / FAT32 directory profile:
>
None of this is truly relevant; these could have been any files
regularly accessed on a FAT partition. I think you need to reevaluate
your profile sharing solution, and keep your data on a more robust
filesystem. Right now, you are managing gold bullion with a closet
organizer... :-)
GL
On 05/03/12 06:02 am, David Arturo Macias Corona thus wrote :
> Sorry for duplicate
> I am moving from "test build2" message to own message
>
> Please check message below
>
> David Macias
>
>
> Maybe this is a "well known" problem, but not for me
> If somebody knows solution(s) please re-direct me
>
> I have a lot of years using Mozilla and later Seamonkey on OS/2
> Currently:
> - eCS 2.0
> - Build identifier: Mozilla/5.0 (OS/2; Warp 4.5; rv:10.0.2)
> Gecko/20120216 Firefox/10.0.2 SeaMonkey/2.7
>
> When I jumped from Seamonkey 1.1.19 to 2.x series, a lot of problems raised
>
Indeed, the switch to toolkit did bring along with it a number of
> I am moving from "test build2" message to own message
>
> Please check message below
>
> David Macias
>
>
> Maybe this is a "well known" problem, but not for me
> If somebody knows solution(s) please re-direct me
>
> I have a lot of years using Mozilla and later Seamonkey on OS/2
> Currently:
> - eCS 2.0
> - Build identifier: Mozilla/5.0 (OS/2; Warp 4.5; rv:10.0.2)
> Gecko/20120216 Firefox/10.0.2 SeaMonkey/2.7
>
> When I jumped from Seamonkey 1.1.19 to 2.x series, a lot of problems raised
>
issues, though recent builds have come a long way since 2.0. That said,
2.7 is probably not as solid as 2.6 (on OS/2, at least).
> I installed a long time ago Seamonkey 2.0 and Samba server with two days
> difference, so problems from each one appeared mixed
> At closing eCS it hang at "releasing filesystems", then I found it is
> caused by Samba server, so I start it manually when I need and that
> problem disappear
>
ticket about it. I stopped using Samba server on my eCS 1.2 web server
some time ago, in an effort to just trim down things which were not in
daily use but taking up resources. I do all of my remote file transfers
to and from that box via FTP, now.
> For Seamonkey, I share main profile with SM-OS/2 and SM-Windows on a
> FAT32 partition/directory, but I use SM-Windows rarely
> Even if I do not use SM-Windows, SM-OS/2 files appear damaged/corrupted
> very often, with problem of any kind
>
> Most of times are problems with sessionstore*.json files ( CHKDSK on
> Windows find them corrupted ), but other times are another files
> Most recent problem was places.sqlite-wal file
>
has been due to lazywriting and timing issues. Disable CACHEF32's
lazywrite with the /L:OFF or completely REM the call to CACHEF32.EXE in
CONFIG.SYS & reboot.
> Below is a list of some sessionstore*.json files, which are a mix of
> good and corrupted files
> Corrupted files refused to copy using XCOPY or COPY
> SM-OS/2 are creating those files increasing numbering, and some of them
> are corrupted. Time ago it was around 80 files, and I deleted them from
> time to time
> Some weeks ago SM-OS/2 was too slow, and I found around 6 files with
> around 500 Mbytes file size with different numbering. After deleting
> them SM-OS/2 was near "fine" ago
> Usual file size is around 3 Mb, but not 500 Mb
>
disastrous consequences. The best of all worlds would be to keep your
profile on a JFS partition and then using the NTFS NetDrive plugin to
mount an NTFS partition, just have a script rsync your profile from the
JFS volume to the NTFS volume. Remember that under the *best*
circumstances, FAT32 is a risky proposition. As Felix recently wrote on
another forum, in a thread related to FAT32-Ext/ExFAT32and which are
words to live by, "lowest possible robustness."
Both JFS and NTFS are journaling filesystems, making them infinitely
better suited to maintaining transaction-oriented data (database files)
than *any* FAT variant.
> When problem happen most of time is Seamonkey blank screen, missing
> opened tabs
> Then I start to copy from my Seamonkey backups one file at a time, until
> everything is restored
> Based on this, I know corrupted case is in any file
>
> I have checked with profiles, now I have five
> - Main profile, on FAT32
> - 2,3,4,5 profiles, on HPFS
>
> Only profile on FAT32 show this problem, so I conclude it as an problem
> between SM-OS/2 and FAT32 partition/driver
>
> Only happen in SM 2.x series, and does not happen in SM 1.x series
>
> Due this problem, I try not to use main profile, but it manage my Mail :-(
> and I want to mantain as is, on FAT32, to access from Windows when I
> need it
> And I do not want to change to FF-Thunderbird
> I try to have fixed this problem with SM-OS2-FAT32
>
easily be having the same conversation about MySQL database files as we
are concerning sqlite database files. The problem is the filesystem and
what you are trying to do with it. The fact that the problem is more
likely to appear using the FAT32 IFS under OS/2 is immaterial, as FAT32
even on Windows would be vulnerable to corruption.
> How often this problem happen ? Randomly
> It may crash two or three times on a day, or crash two or three days in
> between
>
> If somebody want to try, just create an SM 2.x profile on FAT32
> partition and use it heavily some days with 3 to 7 tabs
>
use FAT32 for storage and shuttling *static* files between different
disconnected systems. ;-)
> Somebody knows about this problem and their solutions ?
>
> This is result of last repair with Windows CHKDSK
> All damaged files were found in SM / FAT32 directory profile:
>
regularly accessed on a FAT partition. I think you need to reevaluate
your profile sharing solution, and keep your data on a more robust
filesystem. Right now, you are managing gold bullion with a closet
organizer... :-)
GL
Ray Davison
May 3, 2012, 11:19:38 AM5/3/12
to
David Arturo Macias Corona wrote:
> For Seamonkey, I share main profile with SM-OS/2 and SM-Windows on a
> FAT32 partition/directory, but I use SM-Windows rarely
I too have long shared SM profiles between OS/2-eCS and Win2K-WinXP.
> For Seamonkey, I share main profile with SM-OS/2 and SM-Windows on a
> FAT32 partition/directory, but I use SM-Windows rarely
Both apps and data have always been on Fat32; apps on an apps partition
and data on a data partition. I have kept copies of SM-1119 for both
eCS and Win. I currently use 2.7.2 for eCS and 2.9.1 for Win. I prefer
to use eCS but shopping requires Flash so I use WinXP a lot.
I do flush the cache on exit. I only started doing this with the recent
change in the way cache is handled.
It has worked very well for me. The only corruption I can recall was
one mail file.
Using "better" file systems would mean not sharing, and that would mean
maintaining multiple databases, and in my world that has always been
something to avoid. I once tried Ext2, don't find notes on why I gave
up on it.
As for how Samba might effect all this, I have no idea because I have
never used it.
Ray
Dave Yeo
May 3, 2012, 11:43:36 AM5/3/12
to
Ray Davison wrote:
> David Arturo Macias Corona wrote:
>
>> For Seamonkey, I share main profile with SM-OS/2 and SM-Windows on a
>> FAT32 partition/directory, but I use SM-Windows rarely
>
> I too have long shared SM profiles between OS/2-eCS and Win2K-WinXP.
> Both apps and data have always been on Fat32; apps on an apps partition
> and data on a data partition. I have kept copies of SM-1119 for both eCS
> and Win. I currently use 2.7.2 for eCS and 2.9.1 for Win. I prefer to
> use eCS but shopping requires Flash so I use WinXP a lot.
>
> I do flush the cache on exit. I only started doing this with the recent
> change in the way cache is handled.
>
> It has worked very well for me. The only corruption I can recall was one
> mail file.
[...]
> David Arturo Macias Corona wrote:
>
>> For Seamonkey, I share main profile with SM-OS/2 and SM-Windows on a
>> FAT32 partition/directory, but I use SM-Windows rarely
>
> I too have long shared SM profiles between OS/2-eCS and Win2K-WinXP.
> Both apps and data have always been on Fat32; apps on an apps partition
> and data on a data partition. I have kept copies of SM-1119 for both eCS
> and Win. I currently use 2.7.2 for eCS and 2.9.1 for Win. I prefer to
> use eCS but shopping requires Flash so I use WinXP a lot.
>
> I do flush the cache on exit. I only started doing this with the recent
> change in the way cache is handled.
>
> It has worked very well for me. The only corruption I can recall was one
> mail file.
Perhaps you can post your config.sys settings for FAT32?
Dave
Ray Davison
May 4, 2012, 5:40:52 PM5/4/12
to
Dave Yeo wrote:
>
> Perhaps you can post your config.sys settings for FAT32?
Is this what you are referring to?
>
> Perhaps you can post your config.sys settings for FAT32?
IFS=E:\ECS\BOOT\FAT32.IFS /CACHE:2048 /H /Q
CALL=E:\ECS\BIN\CACHEF32.EXE /S /F
Ray
Dave Yeo
May 4, 2012, 11:53:58 PM5/4/12
to
can compare.
Dave
Heikki Kekki
May 5, 2012, 3:09:39 AM5/5/12
to
IFS=E:\OS2\BOOT\FAT32.IFS /CACHE:2048 /H /Q
CALL=E:\OS2\CACHEF32.EXE /S /F /L:OFF
No problem except I can't write larger than 2 GiB file on FAT32.
--
Hessu
Feel free to correct my English :-)
Dave Yeo
May 5, 2012, 3:51:55 AM5/5/12
to dev-po...@lists.mozilla.org
On 05/05/12 12:09 am, Heikki Kekki wrote:
> No problem except I can't write larger than 2 GiB file on FAT32.
I understand that this is due to the type that was used and at least by
> No problem except I can't write larger than 2 GiB file on FAT32.
recompiling with uint32 4 GB files should be possible.
Don't know if using, IIRC, type_t would allow larger ones.
Dave
Alfredo Fernández Díaz
May 5, 2012, 4:23:35 AM5/5/12
to
Dave Yeo just wrote:
> On 05/05/12 12:09 am, Heikki Kekki wrote:
>> No problem except I can't write larger than 2 GiB file on FAT32.
>
> I understand that this is due to the type that was used and at least by
> recompiling with uint32 4 GB files should be possible.
Mmh, good to know.
> On 05/05/12 12:09 am, Heikki Kekki wrote:
>> No problem except I can't write larger than 2 GiB file on FAT32.
>
> I understand that this is due to the type that was used and at least by
> recompiling with uint32 4 GB files should be possible.
> Don't know if using, IIRC, type_t would allow larger ones.
Alfredo.
Paul Ratcliffe
May 5, 2012, 6:31:46 AM5/5/12
to
On Sat, 05 May 2012 00:51:55 -0700, Dave Yeo <dave....@gmail.com> wrote:
> On 05/05/12 12:09 am, Heikki Kekki wrote:
>> No problem except I can't write larger than 2 GiB file on FAT32.
>
> I understand that this is due to the type that was used and at least by
> recompiling with uint32 4 GB files should be possible.
Don't be ridiculous.
> On 05/05/12 12:09 am, Heikki Kekki wrote:
>> No problem except I can't write larger than 2 GiB file on FAT32.
>
> I understand that this is due to the type that was used and at least by
> recompiling with uint32 4 GB files should be possible.
You need to implement different APIs in the filesystem driver to
support >2GB files. Types of variables used by the compiler is largely
irrelevant.
Heikki Kekki
May 5, 2012, 2:35:31 PM5/5/12
to
file size 1 byte, but dir shows correct size. Maybe there is something
obsolete in my system (eCS 1.1).
Dave Yeo
May 5, 2012, 3:34:51 PM5/5/12
to
Dave
Allan
May 5, 2012, 9:27:37 PM5/5/12
to
On Sat, 5 May 2012 07:09:39 UTC, "Heikki Kekki" <kekk...@sgic.fi.invalid> wrote:
> No problem except I can't write larger than 2 GiB file on FAT32.
Of course you can't, as the IFS for eCS doesn't support it.
> No problem except I can't write larger than 2 GiB file on FAT32.
--
Allan.
It is better to close your mouth, and look like a fool,
than to open it, and remove all doubt.
David Arturo Macias Corona
May 9, 2012, 4:59:17 AM5/9/12
to
>>> IFS=E:\ECS\BOOT\FAT32.IFS /CACHE:2048 /H /Q
>>> CALL=E:\ECS\BIN\CACHEF32.EXE /S /F
>>> CALL=E:\ECS\BIN\CACHEF32.EXE /S /F
> I have
>
> IFS=E:\OS2\BOOT\FAT32.IFS /CACHE:2048 /H /Q
> CALL=E:\OS2\CACHEF32.EXE /S /F /L:OFF
>
Thanks to everyone
>
> IFS=E:\OS2\BOOT\FAT32.IFS /CACHE:2048 /H /Q
> CALL=E:\OS2\CACHEF32.EXE /S /F /L:OFF
>
Mine are, as eCS 2.0 set:
IFS=E:\ECS\BOOT\FAT32.IFS /CACHE:2048 /H /Q /EAS
CALL=E:\ECS\BIN\CACHEF32.EXE /S /F
and for version:
-------------------------------
[E:\]chkdsk d:
The current hard disk drive is: D:
The type of file system for the disk is FAT32.
The FAT32 file system program has been started.
(UFAT32.DLL version 0.9.12 compiled on Apr 15 2008)
-------------------------------
When I issued chkdsk d: to review version I noted something, so I
checked further
I made a long series of tests during days, but results are mixed and I
can not establish conclusions
Maybe some one more experienced and with more knowledge can explain
Tests were in:
Windows Vista Ultimate: c:ntfs and d:fat32
Windows XP: c:ntfs and d:fat32
eCS 2.0: d:fat32 and e:hpfs
eCS 2.0, eCS 2.1, new installations, new Seamonkey: d:fat32 and e:hpfs
Only Windows Vista ntfs and fat32 run completely clean, does not show
any problem
Maybe Win Vista have an strongest handling of fat32 and ntfs, and, in
case of ntfs, may be due:
---------------------------
Transactional NTFS
From Wikipedia, the free encyclopedia
Jump to: navigation, search
Transactional NTFS (abbreviated TxF) is a component of Windows Vista and
later operating systems. It brings the concept of atomic transactions to
the NTFS file system, allowing Windows application developers to write
file output routines that are guaranteed either to succeed completely or
to fail completely.
[...]
Transactional NTFS allows for files and directories to be created,
modified, renamed, and deleted atomically. Using transactions ensures
correctness of operation; in a series of file operations (done as a
transaction), the operation will be committed if all the operations
succeed. In case of any failure, the entire operation will rollback and
fail.
---------------------------
I made tests with SeaMonkey 2.7.2 already installed or new installed in
some cases, and profiles already configured or new ones
Tested too with SeaMonkey 1.x series in some cases
And firefox which come in eCS 2.1
What I noted and made tests in summary is:
(a) If Seamonkey 2.7.x ( or firefox, or old Seamonkey 1.x series ) are
open / running, CHKDSK show random "allocation error" in files of
profile in use
I guess is due they are open and/or exclusive use
(b) When Seamonkey close, these random "allocation error" disappear
But always ?
Some examples are:
------------------------------
Running Seamonkey 2.7.2 OS/2, d:fat32 profile:
File allocation error detected for D:\moz2fat32\cookies.sqlite-wal
File allocation error detected for D:\moz2fat32\Cache\_CACHE_001_
File allocation error detected for D:\moz2fat32\Cache\_CACHE_002_
File allocation error detected for D:\moz2fat32\Cache\_CACHE_003_
------------------------------
Running Seamonkey 2.7.2 OS/2, e:hpfs profile:
CHKDSK corrected an allocation error for the file \moz2hpfs\places.sqlite-w.
CHKDSK corrected an allocation error for the file \moz2hpfs\addons.sqlite-j.
CHKDSK corrected an allocation error for the file \moz2hpfs\extensions.sqli.
CHKDSK corrected an allocation error for the file \moz2hpfs\cert8.db.
CHKDSK corrected an allocation error for the file
\moz2hpfs\Cache\_CACHE_MAP_.
------------------------------
In both cases these are new profiles created for tests
- Does not care if profiles are old or new
- Does not care if profiles was used (navigated many pages) or not
- In most of times is enough to open Seamonkey to see this problem,
without "touching" Seamonkey to navigate
- While CHKDSK is in progress, do not "touch" navigator
When "allocation error" appear after open Seamonkey, I named it
"temporary corrupted files" state
When these files are "fixed" closing Seamonkey, everything is fine
But when these files are not "fixed" closing Seamonkey, I named it
"permanent corrupted files" state
So this is what seem to happen and reported in my original message:
------------------------------
Most of times are problems with sessionstore*.json files ( CHKDSK on
Windows find them corrupted ), but other times are another files
Most recent problem was places.sqlite-wal file
------------------------------
Windows find them corrupted ), but other times are another files
Most recent problem was places.sqlite-wal file
Sometimes I need to delete entire Cache directory to "recover" Seamonkey
At last seem that problem happen allways ( "temporary corrupted" ) but
different OS/filesystems handle them different
Happen in Windows XP/fat32 too, but not Windows Vista
Maybe os/2-hpfs handles "gracefully" this "allocation error" so they
rarely end as "permanent corrupted"
CHKDSK say:
CHKDSK corrected an allocation error
In this case eCS-FAT32 IFS result weakest so these "allocation error"
are not handled properly and sometimes end as "permanent corrupted",
what I see very often and cause of original message
Why happen often in Seamonkey 2.x series and not in Seamonkey 1.x ?
I think is due 2.x series is using "stronger database management", as sqlite
Many of us remember how this was an weak area in first 2.x releases
Warning:
If someone want to try, make NEW profiles for tests
- Open Seamonkey 2.7.2 ( or any 2.x series )
- Create new profiles in fat32 and hpfs
and then:
- Open Seamonkey and choose profile to test
- Run CHKDSK (drive of profile). Do not touch Seamonkey until end
- Close Seamonkey
- Run CHKDSK (drive of profile)
If there are not differences, try again, ... and again, and again, in
sometime it may happen
I used
chkdsk (drive) > outputNN.txt 2>&1
and have more than 40 files :-)
Can some one explain deeper this behaviour ?
Can be this the cause of problems reported in "SeaMonkey 2.x and FAT32" ?
David Macias
Dave Yeo
May 9, 2012, 11:00:10 AM5/9/12
to
David Arturo Macias Corona wrote:
>>>> IFS=E:\ECS\BOOT\FAT32.IFS /CACHE:2048 /H /Q
>>>> CALL=E:\ECS\BIN\CACHEF32.EXE /S /F
>> I have
>>
>> IFS=E:\OS2\BOOT\FAT32.IFS /CACHE:2048 /H /Q
>> CALL=E:\OS2\CACHEF32.EXE /S /F /L:OFF
>>
>
> Thanks to everyone
>
> Mine are, as eCS 2.0 set:
>
> IFS=E:\ECS\BOOT\FAT32.IFS /CACHE:2048 /H /Q /EAS
> CALL=E:\ECS\BIN\CACHEF32.EXE /S /F
Try testing without /EAS. Seems I've heard this can be problematic.
>>>> CALL=E:\ECS\BIN\CACHEF32.EXE /S /F
>> I have
>>
>> IFS=E:\OS2\BOOT\FAT32.IFS /CACHE:2048 /H /Q
>> CALL=E:\OS2\CACHEF32.EXE /S /F /L:OFF
>>
>
> Thanks to everyone
>
> Mine are, as eCS 2.0 set:
>
> IFS=E:\ECS\BOOT\FAT32.IFS /CACHE:2048 /H /Q /EAS
> CALL=E:\ECS\BIN\CACHEF32.EXE /S /F
Dave
David Arturo Macias Corona
May 13, 2012, 10:48:55 PM5/13/12
to
Dave, thanks:
Dave Yeo wrote:
>> IFS=E:\ECS\BOOT\FAT32.IFS /CACHE:2048 /H /Q /EAS
>> CALL=E:\ECS\BIN\CACHEF32.EXE /S /F
>
> Try testing without /EAS. Seems I've heard this can be problematic.
> Dave
Now I have many days without /EAS and problems continue
Definitely there are big problems with SeaMonkey 2.x series with FAT32 IFS
FAT32 IFS can not save/close/handle properly files used by SeaMonkey 2.x
series
Below are a description of three of most recent problems
When I send original message to group my interest was:
- Fix my local problems
- To promote a review of case so it can be fixed for everyone
Experts in SeaMonkey 2.x series and/or experts in FAT32 IFS can give a
look at code to see if there are real causes of these problems, so
fixing can be reached changing code in either place, mostly in SeaMonkey
2.x series because rest of programs which use FAT32 does not show these
problems
I show maybe same case is happening in HPFS, but this FS handled
"gracefully" files
The case is open so anyone can follow it
David Macias
Environment
- eCS 2.0 booting in E:HPFS partition
- SeaMonkey 2.7.2 or any 2.x series
- Profile in D:FAT32 including Mail and Newsgroup
Problem 1:
Opening profile D:FAT32 screen appear blank, no tabs open
Deleting entire Cache dir does not fix
Copying an old sessionstore.json fix it
D:\cencar\mozilla2\sessionstore.json1204
Problem 2:
A) Just to be sure I issued from Windows Vista an CHKDSK in D:FAT32
Everything is OK, output is here:
----------------------------------------
Microsoft Windows [Versi¾n 6.0.6001]
Copyright (c) 2006 Microsoft Corporation. Reservados todos los derechos.
C:\Users\Administrador>chkdsk d:
El tipo del sistema de archivos es FAT32.
Volumen WINXPP creado el 16/01/2009 a las 01:05 a.m.
El n·mero de serie del volumen es 496F-DD6D
Windows estß comprobando archivos y carpetas...
Comprobaci¾n de archivo y carpeta completa.
Windows ha comprobado el sistema de archivos y no encontr¾ problemas.
81,875,408 KB de espacio total en disco.
2,263,904 KB en 7,883 archivos ocultos.
434,256 KB en 26,803 carpetas.
65,139,296 KB en 383,025 archivos.
4,944 KB en sectores defectuosos.
14,032,976 KB estßn disponibles.
16,384 bytes en cada unidad de asignaci¾n.
5,117,213 unidades de asignaci¾n en disco en total.
877,061 unidades de asignaci¾n disponibles en disco.
----------------------------------------
B) Then booted from eCS 2.0, open SeaMonkey 2.7.2 + FAT32 profile, read
some mails and this Newsgroup, closed SeaMonkey and eCS 2.7.2
C) Booted from Windows Vista to make an backup of FAT32 profile
XCOPY truncate at checking localstore.rdf file
Output is here:
----------------------------------------
C:\Users\Administrador>xcopy d:\cencar\mozilla2\*.* d:\moz2bak4\*.* /s /e /v
D:\cencar\mozilla2\abook.mab
D:\cencar\mozilla2\compatibility.ini
D:\cencar\mozilla2\downloads.sqlite
D:\cencar\mozilla2\formhistory.sqlite
D:\cencar\mozilla2\history.dat
D:\cencar\mozilla2\history.mab
D:\cencar\mozilla2\mailViews.dat
D:\cencar\mozilla2\panacea.dat
D:\cencar\mozilla2\permissions.sqlite
D:\cencar\mozilla2\search.rdf
D:\cencar\mozilla2\secmod.db
D:\cencar\mozilla2\signons.sqlite
D:\cencar\mozilla2\urlbarhistory.sqlite
D:\cencar\mozilla2\webappsstore.sqlite
D:\cencar\mozilla2\sale.cmd
D:\cencar\mozilla2\extensions.log
D:\cencar\mozilla2\sessionstore.bak0
D:\cencar\mozilla2\xpti.dat
D:\cencar\mozilla2\compreg.dat
D:\cencar\mozilla2\bookmarks.html
D:\cencar\mozilla2\extensions.rdf
D:\cencar\mozilla2\search.sqlite
D:\cencar\mozilla2\search.json
D:\cencar\mozilla2\addons.sqlite
D:\cencar\mozilla2\content-prefs.sqlite
D:\cencar\mozilla2\panels.rdf
D:\cencar\mozilla2\chromeappsstore.sqlite
D:\cencar\mozilla2\sessionstore.json21
D:\cencar\mozilla2\places.sqlite.corrupt
D:\cencar\mozilla2\sale.txt
D:\cencar\mozilla2\sessionstore.json42
D:\cencar\mozilla2\places.sqlite
D:\cencar\mozilla2\sessionstore.json25
D:\cencar\mozilla2\cookies.sqlite.bak
D:\cencar\mozilla2\cookies.sqlite
D:\cencar\mozilla2\mimeTypes.rdf
D:\cencar\mozilla2\places.sqlite.bak
D:\cencar\mozilla2\parent.lock
D:\cencar\mozilla2\extensions.sqlite
D:\cencar\mozilla2\extensions.ini
D:\cencar\mozilla2\sessionstore.json1204
D:\cencar\mozilla2\cert8.db
D:\cencar\mozilla2\key3.db
D:\cencar\mozilla2\global-messages-db.sqlite
D:\cencar\mozilla2\sessionstore-1.json
D:\cencar\mozilla2\virtualFolders.dat
D:\cencar\mozilla2\sessionstore-2.json
D:\cencar\mozilla2\sessionstore.bak
D:\cencar\mozilla2\pluginreg.dat
D:\cencar\mozilla2\cert_override.txt
D:\cencar\mozilla2\blocklist.xml
D:\cencar\mozilla2\localstore.rdf <---- ONE
D:\cencar\mozilla2\sessionstore.json <---- in middle
D:\cencar\mozilla2\localstore.rdf <---- and TWO
Error al comprobar el archivo.
----------------------------------------
Looking for localstore.rdf, it is twice:
----------------------------------------
C:\Users\ADMINI~1>dir d:\cencar\mozilla2\localstore.rdf
El volumen de la unidad D es WINXPP
El n·mero de serie del volumen es: 496F-DD6D
Directorio de d:\cencar\mozilla2
11/05/2012 04:52 p.m. 19,824 localstore.rdf
11/05/2012 05:03 p.m. 19,825 localstore.rdf
2 archivos 39,649 bytes
0 dirs 14,369,751,040 bytes libres
----------------------------------------
Same name file, different time, one bit difference
How were inserted/managed two files with same name ?
Remember, just SeaMonkey 2.7.2 and FAT32 IFS operations were in between
D) Booting from eCS (E: ) and listing, show the same: twice
----------------------------------------
[E:\]dir d:\cencar\mozilla2\localstore.rdf
The volume label in drive D is WINXPP.
The Volume Serial Number is 496F:DD6D.
Directory of D:\cencar\mozilla2
11/05/12 4:52p 19,824 0 a--- localstore.rdf
11/05/12 5:03p 19,825 0 a--- localstore.rdf
2 file(s) 39,649 bytes used
14,369,751 K bytes free
----------------------------------------
E)
This problem was fixed re-booting with Windows Vista and CHKDSK D: /F
Problem 3:
After using SeaMonkey 2.7.2 with FAT32 profile
Then, with SeaMonkey closed, trying to make an backup of FAT32 profile
using XCOPY under eCS:
XCOPY truncate copying:
----------------------------------------
[...]
Source files are being read...
D:\cencar\mozilla2\startupCache\startupCache.4.little
D:\cencar\mozilla2\Cache\_CACHE_MAP_
SYS1186: XCOPY cannot access the source file.
----------------------------------------
Again, delete entire Cache directory to continue
[E:\]help sys1186
SYS1186: XCOPY cannot access the source file.
EXPLANATION: One of the following conditions exists:
o A Cyclic Redundancy Check error.
o The file is in use by another process.
o Too many files are open.
o The diskette is not a DOS diskette.
ACTION: Correct the problem or wait until the file is not in use,
then retry the command.
Dave Yeo wrote:
>> IFS=E:\ECS\BOOT\FAT32.IFS /CACHE:2048 /H /Q /EAS
>> CALL=E:\ECS\BIN\CACHEF32.EXE /S /F
>
> Try testing without /EAS. Seems I've heard this can be problematic.
> Dave
Definitely there are big problems with SeaMonkey 2.x series with FAT32 IFS
FAT32 IFS can not save/close/handle properly files used by SeaMonkey 2.x
series
Below are a description of three of most recent problems
When I send original message to group my interest was:
- Fix my local problems
- To promote a review of case so it can be fixed for everyone
Experts in SeaMonkey 2.x series and/or experts in FAT32 IFS can give a
look at code to see if there are real causes of these problems, so
fixing can be reached changing code in either place, mostly in SeaMonkey
2.x series because rest of programs which use FAT32 does not show these
problems
I show maybe same case is happening in HPFS, but this FS handled
"gracefully" files
The case is open so anyone can follow it
David Macias
Environment
- eCS 2.0 booting in E:HPFS partition
- SeaMonkey 2.7.2 or any 2.x series
- Profile in D:FAT32 including Mail and Newsgroup
Problem 1:
Opening profile D:FAT32 screen appear blank, no tabs open
Deleting entire Cache dir does not fix
Copying an old sessionstore.json fix it
D:\cencar\mozilla2\sessionstore.json1204
Problem 2:
A) Just to be sure I issued from Windows Vista an CHKDSK in D:FAT32
Everything is OK, output is here:
----------------------------------------
Microsoft Windows [Versi¾n 6.0.6001]
Copyright (c) 2006 Microsoft Corporation. Reservados todos los derechos.
C:\Users\Administrador>chkdsk d:
El tipo del sistema de archivos es FAT32.
Volumen WINXPP creado el 16/01/2009 a las 01:05 a.m.
El n·mero de serie del volumen es 496F-DD6D
Windows estß comprobando archivos y carpetas...
Comprobaci¾n de archivo y carpeta completa.
Windows ha comprobado el sistema de archivos y no encontr¾ problemas.
81,875,408 KB de espacio total en disco.
2,263,904 KB en 7,883 archivos ocultos.
434,256 KB en 26,803 carpetas.
65,139,296 KB en 383,025 archivos.
4,944 KB en sectores defectuosos.
14,032,976 KB estßn disponibles.
16,384 bytes en cada unidad de asignaci¾n.
5,117,213 unidades de asignaci¾n en disco en total.
877,061 unidades de asignaci¾n disponibles en disco.
----------------------------------------
B) Then booted from eCS 2.0, open SeaMonkey 2.7.2 + FAT32 profile, read
some mails and this Newsgroup, closed SeaMonkey and eCS 2.7.2
C) Booted from Windows Vista to make an backup of FAT32 profile
XCOPY truncate at checking localstore.rdf file
Output is here:
----------------------------------------
C:\Users\Administrador>xcopy d:\cencar\mozilla2\*.* d:\moz2bak4\*.* /s /e /v
D:\cencar\mozilla2\abook.mab
D:\cencar\mozilla2\compatibility.ini
D:\cencar\mozilla2\downloads.sqlite
D:\cencar\mozilla2\formhistory.sqlite
D:\cencar\mozilla2\history.dat
D:\cencar\mozilla2\history.mab
D:\cencar\mozilla2\mailViews.dat
D:\cencar\mozilla2\panacea.dat
D:\cencar\mozilla2\permissions.sqlite
D:\cencar\mozilla2\search.rdf
D:\cencar\mozilla2\secmod.db
D:\cencar\mozilla2\signons.sqlite
D:\cencar\mozilla2\urlbarhistory.sqlite
D:\cencar\mozilla2\webappsstore.sqlite
D:\cencar\mozilla2\sale.cmd
D:\cencar\mozilla2\extensions.log
D:\cencar\mozilla2\sessionstore.bak0
D:\cencar\mozilla2\xpti.dat
D:\cencar\mozilla2\compreg.dat
D:\cencar\mozilla2\bookmarks.html
D:\cencar\mozilla2\extensions.rdf
D:\cencar\mozilla2\search.sqlite
D:\cencar\mozilla2\search.json
D:\cencar\mozilla2\addons.sqlite
D:\cencar\mozilla2\content-prefs.sqlite
D:\cencar\mozilla2\panels.rdf
D:\cencar\mozilla2\chromeappsstore.sqlite
D:\cencar\mozilla2\sessionstore.json21
D:\cencar\mozilla2\places.sqlite.corrupt
D:\cencar\mozilla2\sale.txt
D:\cencar\mozilla2\sessionstore.json42
D:\cencar\mozilla2\places.sqlite
D:\cencar\mozilla2\sessionstore.json25
D:\cencar\mozilla2\cookies.sqlite.bak
D:\cencar\mozilla2\cookies.sqlite
D:\cencar\mozilla2\mimeTypes.rdf
D:\cencar\mozilla2\places.sqlite.bak
D:\cencar\mozilla2\parent.lock
D:\cencar\mozilla2\extensions.sqlite
D:\cencar\mozilla2\extensions.ini
D:\cencar\mozilla2\sessionstore.json1204
D:\cencar\mozilla2\cert8.db
D:\cencar\mozilla2\key3.db
D:\cencar\mozilla2\global-messages-db.sqlite
D:\cencar\mozilla2\sessionstore-1.json
D:\cencar\mozilla2\virtualFolders.dat
D:\cencar\mozilla2\sessionstore-2.json
D:\cencar\mozilla2\sessionstore.bak
D:\cencar\mozilla2\pluginreg.dat
D:\cencar\mozilla2\cert_override.txt
D:\cencar\mozilla2\blocklist.xml
D:\cencar\mozilla2\localstore.rdf <---- ONE
D:\cencar\mozilla2\sessionstore.json <---- in middle
D:\cencar\mozilla2\localstore.rdf <---- and TWO
Error al comprobar el archivo.
----------------------------------------
Looking for localstore.rdf, it is twice:
----------------------------------------
C:\Users\ADMINI~1>dir d:\cencar\mozilla2\localstore.rdf
El volumen de la unidad D es WINXPP
El n·mero de serie del volumen es: 496F-DD6D
Directorio de d:\cencar\mozilla2
11/05/2012 04:52 p.m. 19,824 localstore.rdf
11/05/2012 05:03 p.m. 19,825 localstore.rdf
2 archivos 39,649 bytes
0 dirs 14,369,751,040 bytes libres
----------------------------------------
Same name file, different time, one bit difference
How were inserted/managed two files with same name ?
Remember, just SeaMonkey 2.7.2 and FAT32 IFS operations were in between
D) Booting from eCS (E: ) and listing, show the same: twice
----------------------------------------
[E:\]dir d:\cencar\mozilla2\localstore.rdf
The volume label in drive D is WINXPP.
The Volume Serial Number is 496F:DD6D.
11/05/12 4:52p 19,824 0 a--- localstore.rdf
11/05/12 5:03p 19,825 0 a--- localstore.rdf
2 file(s) 39,649 bytes used
14,369,751 K bytes free
----------------------------------------
E)
This problem was fixed re-booting with Windows Vista and CHKDSK D: /F
Problem 3:
After using SeaMonkey 2.7.2 with FAT32 profile
Then, with SeaMonkey closed, trying to make an backup of FAT32 profile
using XCOPY under eCS:
XCOPY truncate copying:
----------------------------------------
[...]
Source files are being read...
D:\cencar\mozilla2\startupCache\startupCache.4.little
D:\cencar\mozilla2\Cache\_CACHE_MAP_
SYS1186: XCOPY cannot access the source file.
----------------------------------------
Again, delete entire Cache directory to continue
[E:\]help sys1186
SYS1186: XCOPY cannot access the source file.
EXPLANATION: One of the following conditions exists:
o A Cyclic Redundancy Check error.
o The file is in use by another process.
o Too many files are open.
o The diskette is not a DOS diskette.
ACTION: Correct the problem or wait until the file is not in use,
then retry the command.
Dave Yeo
May 14, 2012, 12:05:26 AM5/14/12
to
David Arturo Macias Corona wrote:
> Dave, thanks:
>
> Dave Yeo wrote:
>>> IFS=E:\ECS\BOOT\FAT32.IFS /CACHE:2048 /H /Q /EAS
>>> CALL=E:\ECS\BIN\CACHEF32.EXE /S /F
>>
>> Try testing without /EAS. Seems I've heard this can be problematic.
>> Dave
>
> Now I have many days without /EAS and problems continue
>
> Definitely there are big problems with SeaMonkey 2.x series with FAT32 IFS
> FAT32 IFS can not save/close/handle properly files used by SeaMonkey 2.x
> series
>
> Below are a description of three of most recent problems
[...]
>
> Dave Yeo wrote:
>>> IFS=E:\ECS\BOOT\FAT32.IFS /CACHE:2048 /H /Q /EAS
>>> CALL=E:\ECS\BIN\CACHEF32.EXE /S /F
>>
>> Try testing without /EAS. Seems I've heard this can be problematic.
>> Dave
>
> Now I have many days without /EAS and problems continue
>
> Definitely there are big problems with SeaMonkey 2.x series with FAT32 IFS
> FAT32 IFS can not save/close/handle properly files used by SeaMonkey 2.x
> series
>
> Below are a description of three of most recent problems
I really don't know what to say. As Ray commented, he has successfully
been using fat32 and SeaMonkey 2.x for a long time. Nothing has changed
in the way SeaMonkey handles files, using the OS/2 API for file related
stuff. It does do more file I/O then previous versions and also uses
quite a bit of memory.
The FAT32 driver isn't the best piece of work and fat32 itself is a
kludge, supporting both long and short file names (I wonder if your
duplicate files have different short names) but a lot of people use it
successfully. Some do report faster usage without the cache so that is
one thing you could try to disable and I guess you could try reducing
virtualaddresslimit in config.sys on the odd chance that it is too high
on your system. Also wouldn't hurt to use something like DFSee to verify
your hard drive doesn't have problems.
Perhaps others have suggestions
Dave
David Arturo Macias Corona
May 19, 2012, 9:11:58 PM5/19/12
to
Dave, thanks:
>I really don't know what to say. As Ray commented, he has
>successfully been using fat32 and SeaMonkey 2.x for a long time.
VIRTUALADDRESSLIMIT=1536
My next test was with CACHE changes
After your reference to Cache I checked remark of Lewis Rosenthal who
made a detailed response to my message (thanks Lewis):
"In my experience, 99% of the time, corruption in FAT32 files under eCS
has been due to lazywriting and timing issues. Disable CACHEF32's
lazywrite with the /L:OFF or completely REM the call to CACHEF32.EXE in
CONFIG.SYS & reboot. "
Now I have in CONFIG.sys
REM TESTS SEAMONKEY 2.x SERIES CALL=E:\ECS\BIN\CACHEF32.EXE /S /F
After many days of use, situation is highly different and too much better
Just one problem of duplicate files:
-------------------------------------
[D:\cencar\mozilla2]dir sessionstore.json /od
The volume label in drive D is WINXPP.
The Volume Serial Number is 496F:DD6D.
Directory of D:\cencar\mozilla2
15/05/12 2:05a 4,069,758 0 a--- sessionstore.json
15/05/12 2:18a 154 0 a--- sessionstore.json
2 file(s) 4,069,912 bytes used
-------------------------------------
But just ONE problem in many days is wonderful, everything is more
stable and now I live happy :-)
Solution seem to be excluding CACHEF32.EXE for SeaMonkey 2.x series
so I left it "for the record" and recommendation to everyone
>Also wouldn't hurt to use something like DFSee to verify your hard
>drive doesn't have problems.
DFsee 11.1 show for D:FAT32:
----------------------------------------
Pid02=D: warning :
Bootsector HiddenSectors field does NOT match part-table!
It may be harmless, but when it seems to cause problems,
you can probably fix it by opening the partition and use
the FIXPBR command or the corresponding menu item being:
Mode=xxx -> Boot area fixes -> Fix HiddenSectors/Geo value
----------------------------------------
but I checked others three HDD and show same for every FAT32 partitions,
most of them created with Windows XP Pro, so I suppose can be considered
"normal"
David Macias
>I really don't know what to say. As Ray commented, he has
>successfully been using fat32 and SeaMonkey 2.x for a long time.
Ray said:
"I do flush the cache on exit. I only started doing this with the
recent change in the way cache is handled."
I do not know what mean or how to do it:
"I do flush the cache on exit. I only started doing this with the
recent change in the way cache is handled."
"I do flush the cache on exit"
>Some do report faster usage without the cache so that is one thing
>you could try to disable and I guess you could try reducing
>virtualaddresslimit in config.sys on the odd chance that it is too
>high on your system.
This is my value:
>you could try to disable and I guess you could try reducing
>virtualaddresslimit in config.sys on the odd chance that it is too
>high on your system.
VIRTUALADDRESSLIMIT=1536
My next test was with CACHE changes
After your reference to Cache I checked remark of Lewis Rosenthal who
made a detailed response to my message (thanks Lewis):
"In my experience, 99% of the time, corruption in FAT32 files under eCS
has been due to lazywriting and timing issues. Disable CACHEF32's
lazywrite with the /L:OFF or completely REM the call to CACHEF32.EXE in
CONFIG.SYS & reboot. "
REM TESTS SEAMONKEY 2.x SERIES CALL=E:\ECS\BIN\CACHEF32.EXE /S /F
After many days of use, situation is highly different and too much better
Just one problem of duplicate files:
-------------------------------------
[D:\cencar\mozilla2]dir sessionstore.json /od
The volume label in drive D is WINXPP.
The Volume Serial Number is 496F:DD6D.
Directory of D:\cencar\mozilla2
15/05/12 2:18a 154 0 a--- sessionstore.json
2 file(s) 4,069,912 bytes used
-------------------------------------
But just ONE problem in many days is wonderful, everything is more
stable and now I live happy :-)
Solution seem to be excluding CACHEF32.EXE for SeaMonkey 2.x series
so I left it "for the record" and recommendation to everyone
>Also wouldn't hurt to use something like DFSee to verify your hard
>drive doesn't have problems.
----------------------------------------
Pid02=D: warning :
Bootsector HiddenSectors field does NOT match part-table!
It may be harmless, but when it seems to cause problems,
you can probably fix it by opening the partition and use
the FIXPBR command or the corresponding menu item being:
Mode=xxx -> Boot area fixes -> Fix HiddenSectors/Geo value
----------------------------------------
but I checked others three HDD and show same for every FAT32 partitions,
most of them created with Windows XP Pro, so I suppose can be considered
"normal"
David Macias
David Arturo Macias Corona
May 20, 2012, 5:04:05 AM5/20/12
to
>But just ONE problem in many days is wonderful, everything is more
>stable and now I live happy :-)
>Solution seem to be excluding CACHEF32.EXE for SeaMonkey 2.x series
>so I left it "for the record" and recommendation to everyone
The monster is still alive :-)
>stable and now I live happy :-)
>Solution seem to be excluding CACHEF32.EXE for SeaMonkey 2.x series
>so I left it "for the record" and recommendation to everyone
After sending previous message, closing SeaMonkey 2.7.2 (FAT32 profile),
closing eCS 2.0, and hours later, opening eCS 2.0, opening SeaMonkey
2.7.2 (FAT32 profile), appear an beautiful empty window (no tabs opened)
Again, sessionstore.json, .bak truncated, fixed restoring from previous
backup
Now TWO problems in many days are not so wonderful, specially if next
coming problem can not be fixed
Note: now I am using SeaMonkey 2.7.2 esr, focus problem seem reduced
David Macias
Ray Davison
May 21, 2012, 6:15:38 PM5/21/12
to
David Arturo Macias Corona wrote:
> Ray said:
> "I do flush the cache on exit. I only started doing this with the
> recent change in the way cache is handled."
>
> I do not know what mean or how to do it:
> "I do flush the cache on exit"
Browser > Prefs > Privacy & Security > Private data > Always clear, Ask
> "I do flush the cache on exit. I only started doing this with the
> recent change in the way cache is handled."
>
> I do not know what mean or how to do it:
> "I do flush the cache on exit"
me before.
That will cause a check box window to open after the other windows close.
Nine check boxes select the defaults. They can be changed at SM close.
Ray
David Arturo Macias Corona
May 25, 2012, 7:07:55 AM5/25/12
to
Ray, thanks
Ray Davison wrote:
>> "I do flush the cache on exit"
>
> Browser > Prefs > Privacy & Security > Private data > Always clear, Ask
> me before.
>
> That will cause a check box window to open after the other windows close.
> Nine check boxes select the defaults. They can be changed at SM close.
This is not what I expected
Your procedure clear mainly "private data", but what I am trying is to
avoid files corruption using SM 2.x+FAT32 IFS
But your procedure lead me to recall one of my suspects: how "fat" or
"thin" is a profile and consequences in files management
I consider my current FAT32 profile as "fat", while clearing "private
data" result in a "thin" profile and that can be a great difference
As I said in my first message, I want to keep sharing my FAT32 profile
between Windows and OS/2, as ever, due Mail management
- I started using mail sharing between Windows-OS/2 with Eudora Light in
a FAT partition and Win-OS2, d:\cencar\eudora directory
Specifically first mail was in 13 July 1995, a few days later after
starting navigating with Mosaic/Netscape using my new Motorola external
modem and Trumpet WinSock
As I remember, after many tries without response to some addresses,
first response and entirely page displayed was from Cornell University
Windows and OS/2 versions changed along time, and it was working more
than 10 years
Last mail in this environment was in 6 February 2006
- In february 2006 I decided to "modernize" environment using SeaMonkey
1.x + Mail, so I created a new directory and "imported" all from Eudora
to "Local Folders", keeping them separated of new e-mail account folders
Now was Windows-OS/2-FAT32-SeaMonkey 1.x Mail
d:\cencar\mozilla directory
It worked fine from February 2006 to June 2011, five years
- In June 2011 I decided to "modernize" environment using newest
SeaMonkey 2.x series, so I created a new directory and "migrated" all
from SeaMonkey 1.x, as documentation state
Now was Windows-OS/2-FAT32-SeaMonkey 2.x Mail
d:\cencar\mozilla2 directory
Perhaps two days later I started to see problems with SM 2.x series, I
tried other profiles and problems are mainly with that "fat" FAT32
profile which come since Eudora age
I reduced use of SM FAT32 profile to avoid problems but those do not
disappear in next 10 months, so at last SM update (2.7.2) I decided "to
speak" to find solutions
Perhaps reducing profile size many problems will disappear, but many of
my profile data, mail and history may disappear too :-)
Now I am near 17 years of history in navigation and mailing along
current FAT32 profile
David Macias
Ray Davison wrote:
>> "I do flush the cache on exit"
>
> Browser > Prefs > Privacy & Security > Private data > Always clear, Ask
> me before.
>
> That will cause a check box window to open after the other windows close.
> Nine check boxes select the defaults. They can be changed at SM close.
Your procedure clear mainly "private data", but what I am trying is to
avoid files corruption using SM 2.x+FAT32 IFS
But your procedure lead me to recall one of my suspects: how "fat" or
"thin" is a profile and consequences in files management
I consider my current FAT32 profile as "fat", while clearing "private
data" result in a "thin" profile and that can be a great difference
As I said in my first message, I want to keep sharing my FAT32 profile
between Windows and OS/2, as ever, due Mail management
- I started using mail sharing between Windows-OS/2 with Eudora Light in
a FAT partition and Win-OS2, d:\cencar\eudora directory
Specifically first mail was in 13 July 1995, a few days later after
starting navigating with Mosaic/Netscape using my new Motorola external
modem and Trumpet WinSock
As I remember, after many tries without response to some addresses,
first response and entirely page displayed was from Cornell University
Windows and OS/2 versions changed along time, and it was working more
than 10 years
Last mail in this environment was in 6 February 2006
- In february 2006 I decided to "modernize" environment using SeaMonkey
1.x + Mail, so I created a new directory and "imported" all from Eudora
to "Local Folders", keeping them separated of new e-mail account folders
Now was Windows-OS/2-FAT32-SeaMonkey 1.x Mail
d:\cencar\mozilla directory
It worked fine from February 2006 to June 2011, five years
- In June 2011 I decided to "modernize" environment using newest
SeaMonkey 2.x series, so I created a new directory and "migrated" all
from SeaMonkey 1.x, as documentation state
Now was Windows-OS/2-FAT32-SeaMonkey 2.x Mail
d:\cencar\mozilla2 directory
Perhaps two days later I started to see problems with SM 2.x series, I
tried other profiles and problems are mainly with that "fat" FAT32
profile which come since Eudora age
I reduced use of SM FAT32 profile to avoid problems but those do not
disappear in next 10 months, so at last SM update (2.7.2) I decided "to
speak" to find solutions
Perhaps reducing profile size many problems will disappear, but many of
my profile data, mail and history may disappear too :-)
Now I am near 17 years of history in navigation and mailing along
current FAT32 profile
David Macias
David Arturo Macias Corona
May 25, 2012, 8:22:23 AM5/25/12
to
Using SeaMonkey 2.x series and FAT32 profile is an nightmare
After some peaceful days due removing CACHEF32.EXE, problems come again
in more aggressive ways
Now is a high risk to use my FAT32 profile
Any files can get corrupted, so I depend of my last well known backup to
restore files
Most often has been sessionstore.* files damaged, as seen below:
CHKDSK is checking files and directories...
File allocation error detected for D:\cencar\mozilla2\sessionstore.bak
CHKDSK is searching for lost data.
22/05/12 1:03a 4,661,026 0 a--- sessionstore.bak
22/05/12 1:12a 4,661,027 0 a--- sessionstore.json
22/05/12 3:42a 154 0 a--- sessionstore.json
22/05/12 3:42a 37,000 0 a--- prefs.js
24/05/12 5:41a 5,469,004 0 a--- sessionstore.bak
24/05/12 5:42a 5,469,003 0 a--- sessionstore.json
24/05/12 5:44a 393 0 a--- sessionstore.json
sessionstore.bak end as an byte difference up or down to
sessionstore.json size, and appear a second sessionstore.json
Another files damaged can be any of sqlite or db families:
22/05/12 1:00a 4,096 0 a--- urlbarhistory.sqlite
22/05/12 1:12a 2,048 0 a--- permissions.sqlite
22/05/12 1:12a 10,485,760 0 a--- places.sqlite
22/05/12 1:12a 524,288 0 a--- cookies.sqlite
22/05/12 3:42a 98,304 0 a--- cert8.db
22/05/12 3:42a 16,384 0 a--- key3.db
but one damage which worried too much was prefs.js:
22/05/12 3:42a 37,000 0 a--- prefs.js
Prefs.js file size is around 30 Kb, but suddenly it result around 15 Kb
Mail accounts, news accounts and many other values disappeared
Restoring from prefs.js backup safe me
One problem was with places.sqlite appearing a "well-known"
places.sqlite-wal file
These -wal files for places, cookies, ... are common in my corrupted
files problems
So decided to search for "places.sqlite-wal" in Internet and I found a
new world and a conclusion:
"My problems with SeaMonkey 2.x series and FAT32 in OS/2 is a well known
problem of recent Mozilla products in any OS platform"
For example:
-----------------
http://support.mozilla.org/en-US/questions/803069
June 8, 2011
Places.sqlite gets corrupt daily - After ugrading to FF4
-----------------
Main problems seem due to sqlite
and this comment:
----------------------
https://bugzilla.mozilla.org/show_bug.cgi?id=%20625981
Marco Bonardo [:mak] 2011-05-18 10:20:03 PDT
We are again building ideas on vapor. What does make you think the
problem is vacuum? and why discussing it in a bug about wal?
From my point of view, vacuuming at each shutdown would be a pretty bad
choice. The only relevant use for vacuum is whether you cleared all
history, otherwise vacuuming once a month can be more then enough, we
can eventually make the interval customizable. If mobile doesn't ever
fire idle-daily and needs to run it at another time that's another bug
that should be filed.
But please don't overlap bugs.
There is this wal issue to fix, and there is to investigate whether Sync
is pushing too much data to mobile (that causes the db to grow and then
this is practically immediately expired)
----------------------
Mark Finkle (:mfinkle) 2011-05-18 12:34:16 PDT
Very true. I am opening a new bug to look at doing a vacuum when a user
does a "clear private data"
----------------------
2. sqlite *does* attempt to flush the WAL every 16 pages, as we
requested. However, it doesn't always succeed :( If this happens several
times in a row, data accumulates, and the WAL file is enlarged if
necessary. And the WAL file is never shrunk. So one unlucky run of
failures leads to a large, very long living WAL file.
----------------------
Here they are dealing with "grow" of file to un-acceptable values
As I said in first message, I found files of 500 Mb size when usual
sizes are 10 Mb
After these 10 months dealing with these problems and some weeks
supported by your help, I can conclude:
- No OS/2 is guilty
- No FAT32 IFS is guilty
- Recent Mozilla products: FireFox, Thunderbird, SeaMonkey, ... are guilty
As I said, main problems seem due to sqlite and beta sqlite products
trying to deal with these responses, and as Mozilla products share same
engine then share same problems too, in any platform
Internet is plenty of messages about these problems
For sessionstore.json things are not different:
------------------------------
https://bugzilla.mozilla.org/show_bug.cgi?id=670308
Sessions get corrupted randomly (tabs lost after session restore)
2011-07-08
------------------------------
remixedcat 2011-07-22 05:23:57 PDT
mine has occured with no addons as well with a fresh profile... ;-(
------------------------------
Cnon 2011-11-10 18:54:09 PST
It's still broken on FF 8 on Win 7.
------------------------------
Why happen too much often in my Seamonkey 2.x series + FAT32 profile ?
- FAT32 IFS is weak than other FS as HPFS, NTFS, Ext3, ...
- My FAT32 profile may be too "fat", but my Linux and Windows profiles
are too much "fat"
- Some pages on tabs maybe are doing things randomly, but are only 7 tabs
At last I think failures in sqlite family files handling cause processes
truncated which affect other files handling, as example recent prefs.js
failure, due general application failure
I noted after CACHEF32.exe removing Cache directory corruptions has
gone, until now
David Macias
After some peaceful days due removing CACHEF32.EXE, problems come again
in more aggressive ways
Now is a high risk to use my FAT32 profile
Any files can get corrupted, so I depend of my last well known backup to
restore files
Most often has been sessionstore.* files damaged, as seen below:
CHKDSK is checking files and directories...
File allocation error detected for D:\cencar\mozilla2\sessionstore.bak
CHKDSK is searching for lost data.
22/05/12 1:03a 4,661,026 0 a--- sessionstore.bak
22/05/12 1:12a 4,661,027 0 a--- sessionstore.json
22/05/12 3:42a 154 0 a--- sessionstore.json
22/05/12 3:42a 37,000 0 a--- prefs.js
24/05/12 5:41a 5,469,004 0 a--- sessionstore.bak
24/05/12 5:42a 5,469,003 0 a--- sessionstore.json
24/05/12 5:44a 393 0 a--- sessionstore.json
sessionstore.bak end as an byte difference up or down to
sessionstore.json size, and appear a second sessionstore.json
Another files damaged can be any of sqlite or db families:
22/05/12 1:00a 4,096 0 a--- urlbarhistory.sqlite
22/05/12 1:12a 2,048 0 a--- permissions.sqlite
22/05/12 1:12a 10,485,760 0 a--- places.sqlite
22/05/12 1:12a 524,288 0 a--- cookies.sqlite
22/05/12 3:42a 98,304 0 a--- cert8.db
22/05/12 3:42a 16,384 0 a--- key3.db
but one damage which worried too much was prefs.js:
22/05/12 3:42a 37,000 0 a--- prefs.js
Prefs.js file size is around 30 Kb, but suddenly it result around 15 Kb
Mail accounts, news accounts and many other values disappeared
Restoring from prefs.js backup safe me
One problem was with places.sqlite appearing a "well-known"
places.sqlite-wal file
These -wal files for places, cookies, ... are common in my corrupted
files problems
So decided to search for "places.sqlite-wal" in Internet and I found a
new world and a conclusion:
"My problems with SeaMonkey 2.x series and FAT32 in OS/2 is a well known
problem of recent Mozilla products in any OS platform"
For example:
-----------------
http://support.mozilla.org/en-US/questions/803069
June 8, 2011
Places.sqlite gets corrupt daily - After ugrading to FF4
-----------------
Main problems seem due to sqlite
and this comment:
----------------------
https://bugzilla.mozilla.org/show_bug.cgi?id=%20625981
Marco Bonardo [:mak] 2011-05-18 10:20:03 PDT
We are again building ideas on vapor. What does make you think the
problem is vacuum? and why discussing it in a bug about wal?
From my point of view, vacuuming at each shutdown would be a pretty bad
choice. The only relevant use for vacuum is whether you cleared all
history, otherwise vacuuming once a month can be more then enough, we
can eventually make the interval customizable. If mobile doesn't ever
fire idle-daily and needs to run it at another time that's another bug
that should be filed.
But please don't overlap bugs.
There is this wal issue to fix, and there is to investigate whether Sync
is pushing too much data to mobile (that causes the db to grow and then
this is practically immediately expired)
----------------------
Mark Finkle (:mfinkle) 2011-05-18 12:34:16 PDT
Very true. I am opening a new bug to look at doing a vacuum when a user
does a "clear private data"
----------------------
2. sqlite *does* attempt to flush the WAL every 16 pages, as we
requested. However, it doesn't always succeed :( If this happens several
times in a row, data accumulates, and the WAL file is enlarged if
necessary. And the WAL file is never shrunk. So one unlucky run of
failures leads to a large, very long living WAL file.
----------------------
Here they are dealing with "grow" of file to un-acceptable values
As I said in first message, I found files of 500 Mb size when usual
sizes are 10 Mb
After these 10 months dealing with these problems and some weeks
supported by your help, I can conclude:
- No OS/2 is guilty
- No FAT32 IFS is guilty
- Recent Mozilla products: FireFox, Thunderbird, SeaMonkey, ... are guilty
As I said, main problems seem due to sqlite and beta sqlite products
trying to deal with these responses, and as Mozilla products share same
engine then share same problems too, in any platform
Internet is plenty of messages about these problems
For sessionstore.json things are not different:
------------------------------
https://bugzilla.mozilla.org/show_bug.cgi?id=670308
Sessions get corrupted randomly (tabs lost after session restore)
2011-07-08
------------------------------
remixedcat 2011-07-22 05:23:57 PDT
mine has occured with no addons as well with a fresh profile... ;-(
------------------------------
Cnon 2011-11-10 18:54:09 PST
It's still broken on FF 8 on Win 7.
------------------------------
Why happen too much often in my Seamonkey 2.x series + FAT32 profile ?
- FAT32 IFS is weak than other FS as HPFS, NTFS, Ext3, ...
- My FAT32 profile may be too "fat", but my Linux and Windows profiles
are too much "fat"
- Some pages on tabs maybe are doing things randomly, but are only 7 tabs
At last I think failures in sqlite family files handling cause processes
truncated which affect other files handling, as example recent prefs.js
failure, due general application failure
I noted after CACHEF32.exe removing Cache directory corruptions has
gone, until now
David Macias
David Arturo Macias Corona
May 25, 2012, 8:48:16 AM5/25/12
to
In my computer where I have
- Windows Vista, XPP SP2
- eCS20, eCS21
- Many Linux flavors
I used for many years my wireless keyboard+mouse combo with PS/2
connectors, and eveything work fine along years. Labtec brand
Some days ago I bought a new wireless keyboard+mouse combo with USB
receiver. Logitech MK260
Using in ecs20, ecs21, mouse halt response perhaps three times in an
hour as average
- Keyboard continue working without problem, except ONE time
- Removing and inserting mouse battery does not fix
- Removing and inserting USB receiver fix it
I keep removing and removing USB receiver to recover mouse
- Tested with three fresh Logitech packages with same failure
- Tested changing USB ports does not fix
- Tested with recent USBHCD183 does not fix anything
and
- Same computer, Windows flavors and Linux flavors work without problem
any time quantity, including all day
- Tests in other computers with Windows and Linux does not fail
No other computer+ecs2.x tested
So as conclusion ecs2.x have problems dealing with USB receiver which
affect specifically mouse
Any hint except return my wireless keyboard+mouse USB combo ?
David Macias
- Windows Vista, XPP SP2
- eCS20, eCS21
- Many Linux flavors
I used for many years my wireless keyboard+mouse combo with PS/2
connectors, and eveything work fine along years. Labtec brand
Some days ago I bought a new wireless keyboard+mouse combo with USB
receiver. Logitech MK260
Using in ecs20, ecs21, mouse halt response perhaps three times in an
hour as average
- Keyboard continue working without problem, except ONE time
- Removing and inserting mouse battery does not fix
- Removing and inserting USB receiver fix it
I keep removing and removing USB receiver to recover mouse
- Tested with three fresh Logitech packages with same failure
- Tested changing USB ports does not fix
- Tested with recent USBHCD183 does not fix anything
and
- Same computer, Windows flavors and Linux flavors work without problem
any time quantity, including all day
- Tests in other computers with Windows and Linux does not fail
No other computer+ecs2.x tested
So as conclusion ecs2.x have problems dealing with USB receiver which
affect specifically mouse
Any hint except return my wireless keyboard+mouse USB combo ?
David Macias
Lewis Rosenthal
May 25, 2012, 12:34:41 PM5/25/12
to
Hi, David...
On 05/25/12 08:22 am, David Arturo Macias Corona thus wrote :
> One problem was with places.sqlite appearing a "well-known"
> places.sqlite-wal file
> These -wal files for places, cookies, ... are common in my corrupted
> files problems
>
> So decided to search for "places.sqlite-wal" in Internet and I found a
> new world and a conclusion:
>
> "My problems with SeaMonkey 2.x series and FAT32 in OS/2 is a well known
> problem of recent Mozilla products in any OS platform"
>
Not exactly. This is well known for *some* platforms and *some* filesystems.
> For example:
> -----------------
> http://support.mozilla.org/en-US/questions/803069
> June 8, 2011
> Places.sqlite gets corrupt daily - After ugrading to FF4
> -----------------
>
Old...
> Main problems seem due to sqlite
>
I tend to take user comments, thrown out on the table, with no empirical
data to substantiate them as just that: unsubstantiated (unsupported by
facts). These people are talking about observations, and stabbing at
what they "think" might be the problems, when what they are really doing
is stating what they are *seeing* after the fact.
*Anything* which is intercepting disk I/O can cause corruption in open
files, and this is even more of an issue on Windows systems running
anti-virus and anti-malware scanning software full time, and end users
not understanding the impact of not using judicious whitelisting of
files and directories. Thus, they shoot themselves in the foot. These
people are blaming CCleaner (something I use *all* the time -
successfully - on Windows systems to discharge the constant cruft these
systems accumulate due to their lack of automated cleanup routines),
which is more than likely *not* causing *any* file corruption (CCleaner
warns to shut down browsers while it is running, and does not touch open
files).
> and this comment:
> ----------------------
> https://bugzilla.mozilla.org/show_bug.cgi?id=%20625981
> Marco Bonardo [:mak] 2011-05-18 10:20:03 PDT
>
This comment deals with sqlite corruption in a specific file on a
specific platform, and was resolved as WFM. It doesn't really prove
anything, I'm afraid. It does mention instances where the end result can
be similar to what you are seeing, but not a root cause.
<snip - please don't re-post what is already included in a link, unless
you are heavily trimming it>
> Why happen too much often in my Seamonkey 2.x series + FAT32 profile ?
> - FAT32 IFS is weak than other FS as HPFS, NTFS, Ext3, ...
> - My FAT32 profile may be too "fat", but my Linux and Windows profiles
> are too much "fat"
> - Some pages on tabs maybe are doing things randomly, but are only 7 tabs
>
> At last I think failures in sqlite family files handling cause processes
> truncated which affect other files handling, as example recent prefs.js
> failure, due general application failure
>
> I noted after CACHEF32.exe removing Cache directory corruptions has
> gone, until now
>
I'm glad that my suggestion did make some difference for you, though as
I suspected, it is not the entire cause of your data corruption.
*Something* is likely delaying disk writes to the data files. Whether it
is lost CPU cycles due to some files being excessively large
(training.dat, for example) or a bad plugin (Flash content), I cannot say.
If you absolutely *must* continue to share your profile in this manner
(and I would not; Windows and Linux can both read HPFS - Windows, with a
little help - and as you point out, FAT32 is not as robust on OS/2 as
JFS or HPFS, though it is not a good choice on *any* platform for
reasons which I have outlined for you previously), then you should
approach this problem applying more of the scientific method.
1. Create a new profile with *nothing* in it.
2. Either remove your plugins (which are common between profiles) or use
safe mode.
3. Do not install *any* extensions in this test profile.
4. Use this profile for browsing only; do not set up any email accounts
in it.
5. Run it for several hours and watch for sqlite database growth or
leftover wal files after exiting.
Move up from there, with perhaps a second profile including a single
mail account and perhaps a newsgroup or two.
The problem that you have here (with us) is that I doubt very highly
that you will find a significant number of people using your same type
of setup. For years, it has been advised *not* to share profiles between
boot partitions, because odd things can result. In this case, however, I
don't think it's the sharing which is causing it, unless you're only
seeing this after accessing the profile from another OS and/or SM
version. Certainly, testing on your live profile is not a good way to go
about troubleshooting something as potentially damaging as file corruption.
Cheers/2
On 05/25/12 08:22 am, David Arturo Macias Corona thus wrote :
> Using SeaMonkey 2.x series and FAT32 profile is an nightmare
>
> After some peaceful days due removing CACHEF32.EXE, problems come again
> in more aggressive ways
>
> Now is a high risk to use my FAT32 profile
>
> Any files can get corrupted, so I depend of my last well known backup to
> restore files
>
> Most often has been sessionstore.* files damaged, as seen below:
>
<snip>
>
> After some peaceful days due removing CACHEF32.EXE, problems come again
> in more aggressive ways
>
> Now is a high risk to use my FAT32 profile
>
> Any files can get corrupted, so I depend of my last well known backup to
> restore files
>
> Most often has been sessionstore.* files damaged, as seen below:
>
> One problem was with places.sqlite appearing a "well-known"
> places.sqlite-wal file
> These -wal files for places, cookies, ... are common in my corrupted
> files problems
>
> So decided to search for "places.sqlite-wal" in Internet and I found a
> new world and a conclusion:
>
> "My problems with SeaMonkey 2.x series and FAT32 in OS/2 is a well known
> problem of recent Mozilla products in any OS platform"
>
> For example:
> -----------------
> http://support.mozilla.org/en-US/questions/803069
> June 8, 2011
> Places.sqlite gets corrupt daily - After ugrading to FF4
> -----------------
>
> Main problems seem due to sqlite
>
data to substantiate them as just that: unsubstantiated (unsupported by
facts). These people are talking about observations, and stabbing at
what they "think" might be the problems, when what they are really doing
is stating what they are *seeing* after the fact.
*Anything* which is intercepting disk I/O can cause corruption in open
files, and this is even more of an issue on Windows systems running
anti-virus and anti-malware scanning software full time, and end users
not understanding the impact of not using judicious whitelisting of
files and directories. Thus, they shoot themselves in the foot. These
people are blaming CCleaner (something I use *all* the time -
successfully - on Windows systems to discharge the constant cruft these
systems accumulate due to their lack of automated cleanup routines),
which is more than likely *not* causing *any* file corruption (CCleaner
warns to shut down browsers while it is running, and does not touch open
files).
> and this comment:
> ----------------------
> https://bugzilla.mozilla.org/show_bug.cgi?id=%20625981
> Marco Bonardo [:mak] 2011-05-18 10:20:03 PDT
>
specific platform, and was resolved as WFM. It doesn't really prove
anything, I'm afraid. It does mention instances where the end result can
be similar to what you are seeing, but not a root cause.
<snip - please don't re-post what is already included in a link, unless
you are heavily trimming it>
> Why happen too much often in my Seamonkey 2.x series + FAT32 profile ?
> - FAT32 IFS is weak than other FS as HPFS, NTFS, Ext3, ...
> - My FAT32 profile may be too "fat", but my Linux and Windows profiles
> are too much "fat"
> - Some pages on tabs maybe are doing things randomly, but are only 7 tabs
>
> At last I think failures in sqlite family files handling cause processes
> truncated which affect other files handling, as example recent prefs.js
> failure, due general application failure
>
> I noted after CACHEF32.exe removing Cache directory corruptions has
> gone, until now
>
I suspected, it is not the entire cause of your data corruption.
*Something* is likely delaying disk writes to the data files. Whether it
is lost CPU cycles due to some files being excessively large
(training.dat, for example) or a bad plugin (Flash content), I cannot say.
If you absolutely *must* continue to share your profile in this manner
(and I would not; Windows and Linux can both read HPFS - Windows, with a
little help - and as you point out, FAT32 is not as robust on OS/2 as
JFS or HPFS, though it is not a good choice on *any* platform for
reasons which I have outlined for you previously), then you should
approach this problem applying more of the scientific method.
1. Create a new profile with *nothing* in it.
2. Either remove your plugins (which are common between profiles) or use
safe mode.
3. Do not install *any* extensions in this test profile.
4. Use this profile for browsing only; do not set up any email accounts
in it.
5. Run it for several hours and watch for sqlite database growth or
leftover wal files after exiting.
Move up from there, with perhaps a second profile including a single
mail account and perhaps a newsgroup or two.
The problem that you have here (with us) is that I doubt very highly
that you will find a significant number of people using your same type
of setup. For years, it has been advised *not* to share profiles between
boot partitions, because odd things can result. In this case, however, I
don't think it's the sharing which is causing it, unless you're only
seeing this after accessing the profile from another OS and/or SM
version. Certainly, testing on your live profile is not a good way to go
about troubleshooting something as potentially damaging as file corruption.
Cheers/2
Bob
May 25, 2012, 8:05:04 PM5/25/12
to
I have the same symptoms with a Logictech MK320 wireless USB mouse.
IBM/Lenovo Thinkcenter (more than one identical machines). With ECS 2.1
randomly (but within 30 minutes) the mouse stops working. Tried many
different mouse and USB drivers, same result. The wireless keyboard
keeps working. No problems with Windows XP on the same boxes.
David Arturo Macias Corona wrote:
IBM/Lenovo Thinkcenter (more than one identical machines). With ECS 2.1
randomly (but within 30 minutes) the mouse stops working. Tried many
different mouse and USB drivers, same result. The wireless keyboard
keeps working. No problems with Windows XP on the same boxes.
David Arturo Macias Corona wrote:
Alex Taylor
May 26, 2012, 10:05:19 AM5/26/12
to
On Fri, 25 May 2012 12:48:16 UTC, David Arturo Macias Corona
<dma...@mail.udg.mx> wrote:
> Some days ago I bought a new wireless keyboard+mouse combo with USB
> receiver. Logitech MK260
>
> Using in ecs20, ecs21, mouse halt response perhaps three times in an
> hour as average
> - Keyboard continue working without problem, except ONE time
> - Removing and inserting mouse battery does not fix
> - Removing and inserting USB receiver fix it
> I keep removing and removing USB receiver to recover mouse
> - Tested with three fresh Logitech packages with same failure
> - Tested changing USB ports does not fix
> - Tested with recent USBHCD183 does not fix anything
> and
> - Same computer, Windows flavors and Linux flavors work without problem
> any time quantity, including all day
> - Tests in other computers with Windows and Linux does not fail
> No other computer+ecs2.x tested
>
> So as conclusion ecs2.x have problems dealing with USB receiver which
> affect specifically mouse
>
> Any hint except return my wireless keyboard+mouse USB combo ?
I have a similar problem on one particular PC, but it seems to affect
<dma...@mail.udg.mx> wrote:
> Some days ago I bought a new wireless keyboard+mouse combo with USB
> receiver. Logitech MK260
>
> Using in ecs20, ecs21, mouse halt response perhaps three times in an
> hour as average
> - Keyboard continue working without problem, except ONE time
> - Removing and inserting mouse battery does not fix
> - Removing and inserting USB receiver fix it
> I keep removing and removing USB receiver to recover mouse
> - Tested with three fresh Logitech packages with same failure
> - Tested changing USB ports does not fix
> - Tested with recent USBHCD183 does not fix anything
> and
> - Same computer, Windows flavors and Linux flavors work without problem
> any time quantity, including all day
> - Tests in other computers with Windows and Linux does not fail
> No other computer+ecs2.x tested
>
> So as conclusion ecs2.x have problems dealing with USB receiver which
> affect specifically mouse
>
> Any hint except return my wireless keyboard+mouse USB combo ?
any USB mouse, and has ever since I got the current motherboard. The
solution I stumbled upon was to always connect the mouse via a USB hub:
for some reason it doesn't freeze when connected that way, whereas it
constantly freezes when the mouse is plugged directly into any of the
PC's own USB ports.
Alternatively, check your mouse driver. If you're not using AMouse,
install it. If you are using AMouse, try switching to the IBM Single
Mouse Driver.
--
Alex Taylor
Fukushima, Japan
http://www.altsan.org
Please take off hat when replying.
David Arturo Macias Corona
Jun 19, 2012, 7:07:14 AM6/19/12
to
Bob, Alex, thanks
Bob wrote:
> I have the same symptoms with a Logictech MK320 wireless USB mouse.
> IBM/Lenovo Thinkcenter (more than one identical machines). With ECS 2.1
> randomly (but within 30 minutes) the mouse stops working. Tried many
> different mouse and USB drivers, same result. The wireless keyboard
> keeps working. No problems with Windows XP on the same boxes.
I checked another ecs21 machine and have same problem, so is not related
to my first ecs20 machine
My config.sys values are:
DEVICE=E:\ECS\SYSTEM\AMouse\AMOUSE.SYS SMP
DEVICE=E:\ECS\SYSTEM\AMouse\USBMOUSE.SYS
As was hard to work re-connectiong USB receiver every 10 minutes, I am
back with my old and reliable keyb+mouse wireless
How to switch to "IBM Single Mouse Driver" ?
David Macias
Bob wrote:
> I have the same symptoms with a Logictech MK320 wireless USB mouse.
> IBM/Lenovo Thinkcenter (more than one identical machines). With ECS 2.1
> randomly (but within 30 minutes) the mouse stops working. Tried many
> different mouse and USB drivers, same result. The wireless keyboard
> keeps working. No problems with Windows XP on the same boxes.
Alex Taylor wrote:
> I have a similar problem on one particular PC, but it seems to affect
> any USB mouse, and has ever since I got the current motherboard. The
> solution I stumbled upon was to always connect the mouse via a USB hub:
> for some reason it doesn't freeze when connected that way, whereas it
> constantly freezes when the mouse is plugged directly into any of the
> PC's own USB ports.
>
> Alternatively, check your mouse driver. If you're not using AMouse,
> install it. If you are using AMouse, try switching to the IBM Single
> Mouse Driver.
>
So I am not the only one with this problem
> I have a similar problem on one particular PC, but it seems to affect
> any USB mouse, and has ever since I got the current motherboard. The
> solution I stumbled upon was to always connect the mouse via a USB hub:
> for some reason it doesn't freeze when connected that way, whereas it
> constantly freezes when the mouse is plugged directly into any of the
> PC's own USB ports.
>
> Alternatively, check your mouse driver. If you're not using AMouse,
> install it. If you are using AMouse, try switching to the IBM Single
> Mouse Driver.
>
I checked another ecs21 machine and have same problem, so is not related
to my first ecs20 machine
My config.sys values are:
DEVICE=E:\ECS\SYSTEM\AMouse\AMOUSE.SYS SMP
DEVICE=E:\ECS\SYSTEM\AMouse\USBMOUSE.SYS
As was hard to work re-connectiong USB receiver every 10 minutes, I am
back with my old and reliable keyb+mouse wireless
How to switch to "IBM Single Mouse Driver" ?
David Macias
Peter Brown
Jun 20, 2012, 6:35:29 AM6/20/12
to
Hi David
David Arturo Macias Corona wrote:
USB to PS/2 adapters can be useful.
Regards
Pete
David Arturo Macias Corona wrote:
Regards
Pete
David Arturo Macias Corona
Jun 26, 2012, 10:29:25 AM6/26/12
to
Alex:
Alex Taylor wrote:
> I have a similar problem on one particular PC, but it seems to affect
> any USB mouse, and has ever since I got the current motherboard. The
> solution I stumbled upon was to always connect the mouse via a USB hub:
> for some reason it doesn't freeze when connected that way, whereas it
> constantly freezes when the mouse is plugged directly into any of the
> PC's own USB ports.
Investigating other problem where in some of our Linux machines, USB
drives (2.0 or 3.0) disconnect suddenly while copying, damaging files,
with messages like:
-----------------
usb 2-2: device not responding to set addres
usb 2-2: device not acepting address 0, err -71
hub 2-0:1.0: cannot disable port 2 (err= -32)
hub 2-0:1.0: unable to enumerate USB device on port 2
-----------------
I found info like this:
-----------------
If you are using the EHCI (not OTG/MUSB) port, then you have to have a
hub since the board supports only high speed devices.
See http://elinux.org/BeagleBoard#EHCI for the details
-----------------
Part of link info ( BeagleBoard ) are below
Perhaps does not explain problem with USB mouses, but seem very closely,
specially in this part:
-----------------
FS/LS (FullSpeed/LowSpeed) devices, such as keyboards and mice, require
going through a high-speed USB 2.0 hub.
-----------------
David Macias
There are two USB ports on the BeagleBoard, one with an EHCI controller
and another with an OTG controller. As of Rev B4, the usb EHCI has been
removed because of a hardware defect. Rev C will include USB EHCI
working properly.
EHCI
The HS (HighSpeed) USB ECHI controller on OMAP3 on BeagleBoard supports
high-speed only. This simplifies the logic on the device. FS/LS
(FullSpeed/LowSpeed) devices, such as keyboards and mice, require going
through a high-speed USB 2.0 hub.
According to the BeagleBoard System Reference Manual Rev C2, the EHCI
port can source 5V at 500mA which is enough to power a hub and several
low-power devices. However, this is only true if the BeagleBoard is
powered through its power jack from a well-regulated 5V external power
supply. If the BeagleBoard is powered through the OTG port, the EHCI
port sources an "extremely limited" ampount of power (probably 100mA or
so) so you'll need a "self-powered" USB 2.0 hub with its own external
power supply. [Reference: Sections 5.6 and 7.2 of the BBSRM Rev C2.2.]
Hardware issue on rev C3 - the EHCI port on some rev C3 boards is
unstable and will disconnect hubs/devices. Symptoms are: devices are
disconnected from the port and cannot be reconnected without a reboot.
It appears the shared 1.8V rail between the OMAP3530 and the power chip
was getting noisy. Suggested solution (works on many boards) is adding a
22 uF 0805 package SMT capacitor atop the existing cap on C97. If SMT
parts are not available, some boards can be repaired by a 22 uF
through-hole capacitor across GND and VIO_1V8 on the expansion
connector. See [4] for more information.
OTG
The HS USB OTG (OnTheGo) controller on OMAP3 on the BeagleBoard does
have support for all the USB 2.0 speeds (LS/FS/HS) and can act as either
a host or a gadget/device. The HS USB OTG port is used as the default
power input for the BeagleBoard. It is possible to boot the BeagleBoard
using this USB port.
When using the OTG port in host mode, you must power the BeagleBoard
using the +5V power jack. If you connect a USB hub, you'll probably also
need external power for the USB hub as well, because according to the
Hardware Reference manual the BeagleBoard OTG port only sources 100 mA.
This is enough to drive a single low-power device, but probably won't
work with multiple devices.
Alex Taylor wrote:
> I have a similar problem on one particular PC, but it seems to affect
> any USB mouse, and has ever since I got the current motherboard. The
> solution I stumbled upon was to always connect the mouse via a USB hub:
> for some reason it doesn't freeze when connected that way, whereas it
> constantly freezes when the mouse is plugged directly into any of the
> PC's own USB ports.
drives (2.0 or 3.0) disconnect suddenly while copying, damaging files,
with messages like:
-----------------
usb 2-2: device not responding to set addres
usb 2-2: device not acepting address 0, err -71
hub 2-0:1.0: cannot disable port 2 (err= -32)
hub 2-0:1.0: unable to enumerate USB device on port 2
-----------------
I found info like this:
-----------------
If you are using the EHCI (not OTG/MUSB) port, then you have to have a
hub since the board supports only high speed devices.
See http://elinux.org/BeagleBoard#EHCI for the details
-----------------
Part of link info ( BeagleBoard ) are below
Perhaps does not explain problem with USB mouses, but seem very closely,
specially in this part:
-----------------
FS/LS (FullSpeed/LowSpeed) devices, such as keyboards and mice, require
going through a high-speed USB 2.0 hub.
-----------------
David Macias
There are two USB ports on the BeagleBoard, one with an EHCI controller
and another with an OTG controller. As of Rev B4, the usb EHCI has been
removed because of a hardware defect. Rev C will include USB EHCI
working properly.
EHCI
The HS (HighSpeed) USB ECHI controller on OMAP3 on BeagleBoard supports
high-speed only. This simplifies the logic on the device. FS/LS
(FullSpeed/LowSpeed) devices, such as keyboards and mice, require going
through a high-speed USB 2.0 hub.
According to the BeagleBoard System Reference Manual Rev C2, the EHCI
port can source 5V at 500mA which is enough to power a hub and several
low-power devices. However, this is only true if the BeagleBoard is
powered through its power jack from a well-regulated 5V external power
supply. If the BeagleBoard is powered through the OTG port, the EHCI
port sources an "extremely limited" ampount of power (probably 100mA or
so) so you'll need a "self-powered" USB 2.0 hub with its own external
power supply. [Reference: Sections 5.6 and 7.2 of the BBSRM Rev C2.2.]
Hardware issue on rev C3 - the EHCI port on some rev C3 boards is
unstable and will disconnect hubs/devices. Symptoms are: devices are
disconnected from the port and cannot be reconnected without a reboot.
It appears the shared 1.8V rail between the OMAP3530 and the power chip
was getting noisy. Suggested solution (works on many boards) is adding a
22 uF 0805 package SMT capacitor atop the existing cap on C97. If SMT
parts are not available, some boards can be repaired by a 22 uF
through-hole capacitor across GND and VIO_1V8 on the expansion
connector. See [4] for more information.
OTG
The HS USB OTG (OnTheGo) controller on OMAP3 on the BeagleBoard does
have support for all the USB 2.0 speeds (LS/FS/HS) and can act as either
a host or a gadget/device. The HS USB OTG port is used as the default
power input for the BeagleBoard. It is possible to boot the BeagleBoard
using this USB port.
When using the OTG port in host mode, you must power the BeagleBoard
using the +5V power jack. If you connect a USB hub, you'll probably also
need external power for the USB hub as well, because according to the
Hardware Reference manual the BeagleBoard OTG port only sources 100 mA.
This is enough to drive a single low-power device, but probably won't
work with multiple devices.
Alex Taylor
Jun 30, 2012, 6:37:13 AM6/30/12
to
On Tue, 19 Jun 2012 11:07:14 UTC, David Arturo Macias Corona
<dma...@mail.udg.mx> wrote:
> > I have a similar problem on one particular PC, but it seems to affect
> > any USB mouse, and has ever since I got the current motherboard. The
> > solution I stumbled upon was to always connect the mouse via a USB hub:
> > for some reason it doesn't freeze when connected that way, whereas it
> > constantly freezes when the mouse is plugged directly into any of the
> > PC's own USB ports.
> >
> > Alternatively, check your mouse driver. If you're not using AMouse,
> > install it. If you are using AMouse, try switching to the IBM Single
> > Mouse Driver.
>
> So I am not the only one with this problem
> I checked another ecs21 machine and have same problem, so is not related
> to my first ecs20 machine
>
> My config.sys values are:
>
> DEVICE=E:\ECS\SYSTEM\AMouse\AMOUSE.SYS SMP
> DEVICE=E:\ECS\SYSTEM\AMouse\USBMOUSE.SYS
>
> As was hard to work re-connectiong USB receiver every 10 minutes, I am
> back with my old and reliable keyb+mouse wireless
>
> How to switch to "IBM Single Mouse Driver" ?
I think ECSMT can install it.
<dma...@mail.udg.mx> wrote:
> > I have a similar problem on one particular PC, but it seems to affect
> > any USB mouse, and has ever since I got the current motherboard. The
> > solution I stumbled upon was to always connect the mouse via a USB hub:
> > for some reason it doesn't freeze when connected that way, whereas it
> > constantly freezes when the mouse is plugged directly into any of the
> > PC's own USB ports.
> >
> > Alternatively, check your mouse driver. If you're not using AMouse,
> > install it. If you are using AMouse, try switching to the IBM Single
> > Mouse Driver.
>
> So I am not the only one with this problem
> I checked another ecs21 machine and have same problem, so is not related
> to my first ecs20 machine
>
> My config.sys values are:
>
> DEVICE=E:\ECS\SYSTEM\AMouse\AMOUSE.SYS SMP
> DEVICE=E:\ECS\SYSTEM\AMouse\USBMOUSE.SYS
>
> As was hard to work re-connectiong USB receiver every 10 minutes, I am
> back with my old and reliable keyb+mouse wireless
>
> How to switch to "IBM Single Mouse Driver" ?
If you have the files already, I think you can manually make the
switch by commenting out AMOUSE.SYS and USBMAUS.SYS from CONFIG.SYS
and putting DEVICE=<whatever>:\OS2\BOOT\USBMOUSE.SYS in their place.
That'll still leave the AMouse configuration object lying around but
I don't think it hurts anything by being there.
0 new messages