Re: SeaMonkey/2.19 on Linux nuked all messages in InBox and ALL folders underneath

[Jamey Fletcher]

In fact, there is a different explanation for the mark as deleted 
approach.  Depending on how it's handled, it can even make the undeletion 
explanation untenable.

The point of "mark as deleted" was, at least originally, a matter of 
*SPEED*.  MS-DOS would mark a file as deleted in the directory, as well as 
marking the space occupied by the file as free in the FAT tables, rather 
than taking the time to actually over-write the empty spaces immediately.  
When a new file was created in that subdirectory, after a reboot, the 
system would scan the subdirectory file and use the first directory entry 
marked as deleted for the new file directory entry.  Likewise, the FAT 
table would be scanned for placed marked empty - whether they'd ever been 
written to, or not.  This is why, over time, a defragmentation process was 
a good thing - it reduced the fragmentation caused by this process, 
allowing files to be read faster with less head movement.

Likewise, in the MBOX format that many if not most mail programs use, 
simply marking an e-mail as deleted is much faster than the complete 
re-writing of the file that would be necessary for full deletion.  That it 
allows for undeletion is a happy accident, it was not the design goal.  
Compaction allows for the multiple re-writes of the entire MBOX file to be 
done as one long re-write, skipping over e-mails marked deleted.

This is even seen in database engines with fixed-size records - mark a
record deleted, and when it's time to insert a new record, use the space 
from an old deleted record to store the new one.

-- 
Jamey
  <--<@
   ja...@beau.org

___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SeaMonkey/2.19 on Linux nuked all messages in InBox and ALL folders underneath

[Bill Davidsen]

Paul B. Gallagher wrote:

Michael Lueck wrote:

A Williams wrote:

Michael Lueck wrote:


One remaining question... is there some command line way to instruct SM
to gracefully exit if possible (no unsaved emails open, etc...)? I would
require that if I am to automate a daily local backup.


That sounds very risky.  Why not test for the existence of the SM
lock-file?  There has to be a better solution.


I leave SM up "all the time". To do nightly automated backups, I would
have to send SM a message to exit, do the backup, the restart it.

I would check for the mentioned lock-file, and if that still exists,
skip the backup and log the error.

Seems pretty straightforward to me.


Unless you have a VERY slow connection, I see no benefit to leaving SM up to
collect mail while you're in bed. You're not browsing, and you're not installing
software, right? Stock market's probably closed while you are...

Might as well get in the habit of shutting it down when you shut down and
relaunching when you power yourself up. Costs you a minute to get mail as you're
drinking your hot morning beverage, but you get a full, reliable backup. And in
case SM gets cranky when its cache fills up or whatever (been known to happen
with lots of software), the periodic slate-cleaning can improve performance.

Tradeoff's worth it to me, YMMV.

Of course, if you were running something like uTorrent, I could see leaving that
on. But that's not what you said, and uTorrent doesn't require an active browser
to run.

Actually the reason Seamonkey runs on some machines is so I can use the message 
filters to sort incoming mail into folders. And since I might read the IMAP mail 
on the server with another program (Android gmail) I'd like to have the heavy 
lifting done in SM rather than to play with perl or python scripts to do it on 
the mail server.


That's why I want to restart SM, under heavy traffic it leaks, even heamorages 
memory, or at least address space, and the mail filters are very easy to use, a 
great human time saver writing rules.


--
Bill Davidsen 
  We are not out of the woods yet, but we know the direction and have
taken the first step. The steps are many, but finite in number, and if
we persevere we will reach our destination.  -me, 2010


___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SeaMonkey/2.19 on Linux nuked all messages in InBox and ALL folders underneath

[Bill Davidsen]

Michael Lueck wrote:

Greetings,

Since no promising suggestions were made as to where ALL of the folders and
emails disappeared to, I ended up rolling this one account's Inbox and folders
under it back to the last available backup.

One remaining question... is there some command line way to instruct SM to
gracefully exit if possible (no unsaved emails open, etc...)? I would require
that if I am to automate a daily local backup.


cd; find .mozilla -type f -iname Inbox

I have read that "killall -hup seamonkey" works. Note that on some distributions 
that needs to be "seamonkey-bin" depending on something I don't remember.



--
Bill Davidsen 
  We are not out of the woods yet, but we know the direction and have
taken the first step. The steps are many, but finite in number, and if
we persevere we will reach our destination.  -me, 2010


___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SeaMonkey/2.19 on Linux nuked all messages in InBox and ALL folders underneath

[Paul B. Gallagher]

Chris Ilias wrote:

On 2013-07-17 11:00 PM, Paul B. Gallagher wrote:

Chris Ilias wrote:

On 2013-07-17 12:14 PM, Paul B. Gallagher wrote:


The point of doing it this way is to make undo possible.


Are you assuming that is the reason, or do you have a source to cite?


Sorry, didn't realize I had strayed into academia. ;-)

I don't have a source, but it's the only theory that makes any sense.


It's important to be careful not to mislead users. A lot of criticism is
a result of false info.


Why would a programmer or developer go to all the extra trouble of doing
it this way when it would be much simpler and easier to simply do as
Felix says? Only if there were some benefit. And the benefit I outlined
is both obvious and desirable to most users.


It could be any number of reasons that may even be a result of the time
when the decision was made in the 90s.


If you have an alternate hypothesis, I'd be happy to hear it.

--
War doesn't determine who's right, just who's left.
--
Paul B. Gallagher

___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SeaMonkey/2.19 on Linux nuked all messages in InBox and ALL folders underneath

[Chris Ilias]

On 2013-07-17 11:00 PM, Paul B. Gallagher wrote:

Chris Ilias wrote:

On 2013-07-17 12:14 PM, Paul B. Gallagher wrote:


The point of doing it this way is to make undo possible.


Are you assuming that is the reason, or do you have a source to cite?


Sorry, didn't realize I had strayed into academia. ;-)

I don't have a source, but it's the only theory that makes any sense.


It's important to be careful not to mislead users. A lot of criticism is 
a result of false info.



Why would a programmer or developer go to all the extra trouble of doing
it this way when it would be much simpler and easier to simply do as
Felix says? Only if there were some benefit. And the benefit I outlined
is both obvious and desirable to most users.


It could be any number of reasons that may even be a result of the time 
when the decision was made in the 90s.


--
Chris Ilias 
Newsgroup moderator
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SeaMonkey/2.19 on Linux nuked all messages in InBox and ALL folders underneath

[Michael Lueck]

Daniel wrote:


Doesn't lend itself for automation, I suppose!!


Exactly... now you are seeing my point...

--
Michael Lueck
Lueck Data Systems
http://www.lueckdatasystems.com/
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SeaMonkey/2.19 on Linux nuked all messages in InBox and ALL folders underneath

[Daniel]

Michael Lueck wrote:

Daniel wrote:

but could you just copy your profile from its current
location to some other location whilst SM is still operational??



SM might receive an email while the backup is running...



Oh! picky-picky! ;-P How about switching SM off-line then, but I guess 
that's not much different to having to totally re-start SM!?!?


Doesn't lend itself for automation, I suppose!!

--
Daniel

User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20100101 
Firefox/21.0 SeaMonkey/2.18 Build identifier: 20130418192405


or

User agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:21.0) 
Gecko/20100101 Firefox/21.0 SeaMonkey/2.18 Build identifier: 20130403022815

___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SeaMonkey/2.19 on Linux nuked all messages in InBox and ALL folders underneath

[Michael Lueck]

Daniel wrote:

but could you just copy your profile from its current
location to some other location whilst SM is still operational??



SM might receive an email while the backup is running...

--
Michael Lueck
Lueck Data Systems
http://www.lueckdatasystems.com/
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SeaMonkey/2.19 on Linux nuked all messages in InBox and ALL folders underneath

[Daniel]

Michael Lueck wrote:

Greetings,

Since no promising suggestions were made as to where ALL of the folders
and emails disappeared to, I ended up rolling this one account's Inbox
and folders under it back to the last available backup.

One remaining question... is there some command line way to instruct SM
to gracefully exit if possible (no unsaved emails open, etc...)? I would
require that if I am to automate a daily local backup.

Sincerely,


Michael, I've never tried this (and actually have my SM profile on my 
Win7 E:\ disk, so even if I did, it might not be a true reflection), but 
could you just copy your profile from its current location to some other 
location whilst SM is still operational??


--
Daniel

User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20100101 
Firefox/21.0 SeaMonkey/2.18 Build identifier: 20130418192405


or

User agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:21.0) 
Gecko/20100101 Firefox/21.0 SeaMonkey/2.18 Build identifier: 20130403022815

___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SeaMonkey/2.19 on Linux nuked all messages in InBox and ALL folders underneath

[Michael Lueck]

Ed Mullen wrote:


checks for an instance of SM in memory, kills the process (if it exists), and 
then the backup program executes the scheduled backup.


I was hoping for a cross-platform way to script exit SM rather than a brutal 
kill.

Looks like I will have to check for the run file, if there abort, if not there 
then do the nightly backup... type of a scenario.

Sincerely,

--
Michael Lueck
Lueck Data Systems
http://www.lueckdatasystems.com/
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SeaMonkey/2.19 on Linux nuked all messages in InBox and ALL folders underneath

[Ed Mullen]

Michael Lueck wrote:

A Williams wrote:

Michael Lueck wrote:


One remaining question... is there some command line way to instruct SM
to gracefully exit if possible (no unsaved emails open, etc...)? I would
require that if I am to automate a daily local backup.


That sounds very risky.  Why not test for the existence of the SM
lock-file?  There has to be a better solution.


I leave SM up "all the time". To do nightly automated backups, I would
have to send SM a message to exit, do the backup, the restart it.

I would check for the mentioned lock-file, and if that still exists,
skip the backup and log the error.

Seems pretty straight forward to me.

Sincerely,



My backup program allows issuance of a command (Windows .bat or .cmd 
file) prior to running a scheduled backup.  Before any of my systems 
image their system drive (where the SM profile is stored) a "kill 
SeaMonkey process" batch file runs, checks for an instance of SM in 
memory, kills the process (if it exists), and then the backup program 
executes the scheduled backup.


I use similar conditional testing for copying my master calendar program 
(which is maintained on my server) to my laptops.  That is, the batch 
file checks to see if the calendar program is running on the laptop 
before trying to copy the calendar file.  If needed it kills the 
calendar program's process and then copies the file.


If you want more info just ask.

--
Ed Mullen
http://edmullen.net/
"I'm too shy to express my sexual needs except over the phone to people 
I don't know." - Garry Shandling

___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SeaMonkey/2.19 on Linux nuked all messages in InBox and ALL folders underneath

[»Q«]

In ,
Michael Lueck  wrote:

> A Williams wrote:
> > Michael Lueck wrote:
> >
> >> One remaining question... is there some command line way to
> >> instruct SM to gracefully exit if possible (no unsaved emails
> >> open, etc...)? I would require that if I am to automate a daily
> >> local backup.
> >
> > That sounds very risky.  Why not test for the existence of the SM
> > lock-file?  There has to be a better solution.
> 
> I leave SM up "all the time". To do nightly automated backups, I
> would have to send SM a message to exit, do the backup, the restart
> it.
> 
> I would check for the mentioned lock-file, and if that still exists,
> skip the backup and log the error.
> 
> Seems pretty straight forward to me.

Unfortunately, the answer to your question is "no";  see
.

Depending on what window manager you use, there may be a way to tell
the wm to close SeaMonkey's windows, which might effect a graceful
exit.  See 
and , but there's probably
Ubuntu-specific info somewhere about controlling windows with scripts.


___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SeaMonkey/2.19 on Linux nuked all messages in InBox and ALL folders underneath

[Paul B. Gallagher]

Michael Lueck wrote:

A Williams wrote:

Michael Lueck wrote:


One remaining question... is there some command line way to instruct SM
to gracefully exit if possible (no unsaved emails open, etc...)? I would
require that if I am to automate a daily local backup.


That sounds very risky.  Why not test for the existence of the SM
lock-file?  There has to be a better solution.


I leave SM up "all the time". To do nightly automated backups, I would
have to send SM a message to exit, do the backup, the restart it.

I would check for the mentioned lock-file, and if that still exists,
skip the backup and log the error.

Seems pretty straightforward to me.


Unless you have a VERY slow connection, I see no benefit to leaving SM 
up to collect mail while you're in bed. You're not browsing, and you're 
not installing software, right? Stock market's probably closed while you 
are...


Might as well get in the habit of shutting it down when you shut down 
and relaunching when you power yourself up. Costs you a minute to get 
mail as you're drinking your hot morning beverage, but you get a full, 
reliable backup. And in case SM gets cranky when its cache fills up or 
whatever (been known to happen with lots of software), the periodic 
slate-cleaning can improve performance.


Tradeoff's worth it to me, YMMV.

Of course, if you were running something like uTorrent, I could see 
leaving that on. But that's not what you said, and uTorrent doesn't 
require an active browser to run.


--
War doesn't determine who's right, just who's left.
--
Paul B. Gallagher

___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SeaMonkey/2.19 on Linux nuked all messages in InBox and ALL folders underneath

[Felix Miata]

On 2013-07-18 15:14 (GMT+1000) Daniel composed:


Felix Miata wrote:



I compact more often than I empty trash. For
each and every empty trash (normally 20-30 minutes after midnight) I
immediately follow with compact. If I find some fool has emailed me
binaries, after deleting attached binaries I compact the folder they
showed up in before deleting the offending email.



Looks to me like you need to reread what I wrote. What makes you think I
ever compact without first deleting something?



Re-reading ..."I compact more often than I empty trash"  and ...
"deleting attached binaries I compact the folder they showed up in
before deleting the offending email" ... Yeap, seems to me you are, at
times, wasting your time by compacting *before* deleting!!


Re-read it again. The process described is this:

1-"delete" attached binary from message (pretend binary no longer exists; 
consume more disk space)


2-compact folder containing message that contained binary (eradicate binary 
from message and "folder", thus reclaiming the space the binary consumed)


3-"delete" message (pretend compacted message no longer exists; consume more 
disk space)


4-empty trash (pretend messages "moved" to trash no longer exist; consume 
more disk space)


5-compact all folders (eradicate "deleted" messages, regaining space on disk)


O.K., if you just re-boot/re-cycle, I'll give you 23.95/7, maybe, but
not 24/7


Do people who work an "8" hour day _work_ exactly 8.0 hours? I don't know of 
any. Between loo, coffee and other breaks, the vast majority don't even come 
close.


I didn't write 24.0/7.0. I wrote 24/7. If the restart/backup cycle took 1740 
seconds, uptime in days would be 23.517/7.000, which rounds to 24/7. My SM 
restart/backup cycle takes less than 120 seconds, so uptime per day averages 
>23.967 hours.



And with a name like "Felix Miata", I was taking you as Spanish/Mexican,


Felix is derived from Latin, and commonly used by Germans, Austrians and 
those with such ancestry. Miata means reward in Old High German, something 
else in Japanese.



i.e. English not your first language, but then one of the other
contributors here-abouts is "Jay Garcia" and I know he is U.S. of A.'ian
(New Orleans), so, maybe, I should not be so quick to "ASSUME"!!


The bulk of population in EST/EDT -0500/-0400 time zone is in eastern North 
America, which is probably reason enough not to guess Spanish or Mexican.


One can tell nothing purely from an American surname. Nothing requires a USA 
mother to give her surname to her child. Name changes are also legal, and 
were common when Europeans were arriving via ship on Ellis Island. Slave 
owners gave their own names like Wilson, Brown, Smith, Washington, Jefferson 
and many more to their slaves. IOW, the USA is Heinz 57+ territory WRT both 
names and blood.

--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SeaMonkey/2.19 on Linux nuked all messages in InBox and ALL folders underneath

[Michael Lueck]

A Williams wrote:

Michael Lueck wrote:


One remaining question... is there some command line way to instruct SM
to gracefully exit if possible (no unsaved emails open, etc...)? I would
require that if I am to automate a daily local backup.


That sounds very risky.  Why not test for the existence of the SM lock-file?  
There has to be a better solution.


I leave SM up "all the time". To do nightly automated backups, I would have to 
send SM a message to exit, do the backup, the restart it.

I would check for the mentioned lock-file, and if that still exists, skip the 
backup and log the error.

Seems pretty straight forward to me.

Sincerely,

--
Michael Lueck
Lueck Data Systems
http://www.lueckdatasystems.com/
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SeaMonkey/2.19 on Linux nuked all messages in InBox and ALL folders underneath

[A Williams]

Michael Lueck wrote:

Greetings,

Since no promising suggestions were made as to where ALL of the folders
and emails disappeared to, I ended up rolling this one account's Inbox
and folders under it back to the last available backup.

One remaining question... is there some command line way to instruct SM
to gracefully exit if possible (no unsaved emails open, etc...)? I would
require that if I am to automate a daily local backup.

Sincerely,



That sounds very risky.  Why not test for the existence of the SM 
lock-file?  There has to be a better solution.

___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SeaMonkey/2.19 on Linux nuked all messages in InBox and ALL folders underneath

[Michael Lueck]

Greetings,

Since no promising suggestions were made as to where ALL of the folders and 
emails disappeared to, I ended up rolling this one account's Inbox and folders 
under it back to the last available backup.

One remaining question... is there some command line way to instruct SM to 
gracefully exit if possible (no unsaved emails open, etc...)? I would require 
that if I am to automate a daily local backup.

Sincerely,

--
Michael Lueck
Lueck Data Systems
http://www.lueckdatasystems.com/
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SeaMonkey/2.19 on Linux nuked all messages in InBox and ALL folders underneath

[Daniel]

Felix Miata wrote:

On 2013-07-17 20:02 (GMT+1000) Daniel composed:


Felix Miata wrote:



I compact more often than I empty trash. For
each and every empty trash (normally 20-30 minutes after midnight) I
immediately follow with compact. If I find some fool has emailed me
binaries, after deleting attached binaries I compact the folder they
showed up in before deleting the offending email.



Felix, it is my understanding that you are wasting your time compacting
your profile if you haven't, first, deleted the rubbish you want to get
rid of.


Looks to me like you need to reread what I wrote. What makes you think I
ever compact without first deleting something?


Re-reading ..."I compact more often than I empty trash"  and ... 
"deleting attached binaries I compact the folder they showed up in 
before deleting the offending email" ... Yeap, seems to me you are, at 
times, wasting your time by compacting *before* deleting!!



Deleting an e-mail really just marks the e-mail for deletion,


Duh.


I don't know how to respond here!


it is not
actually removed from your inbox file until it is marked for deletion
and then the file is compacted. If an e-mail is not first marked for
deletion, after the compaction it will remain (hidden) in your inbox
file.


If it was up to me, delete would always mean delete rather than hide,
regardless of context. Delete that increases disk consumption by even
one bit is not deletion, it's a lie. Compaction would never be a
separate menu item or process.


.but it's not up to you, yet!! Though the SeaMonkey Council is 
always up for more assistance, so, maybe, in the future, it will be up 
to you!!


However, I tend to agree, deletion should mean it's history, but, on the 
other hand, I have been saved on occasion as mentioned by Paul!! So cal 
me 50/50!!



[re: Geckos] I keep 5 of them open spread across 8 virtual desktops
in the same DE 24/7, save for daily restarts and backups of the profile
used for email.



How can you say you have your DE up 24/7 when you then say you re-boot
daily?? Almost by definition, then, the most you have is up for 24 hours!


AU English must be more different from US than I thought, that or plenty
of after dinner cocktails before reading newsgroups. :-p Again I think
you need to reread.


Yes, U.S. of A.'ian English is very different to Australian English, 
and, most likely posting here *before* dinner, so what do I need to 
re-read??



$ ~/.mozilla> ll */lock
...Jul  9 14:19 .../lock...
...Jul  9 14:24 .../lock...
...Jul  9 13:58 .../lock...
...Jul 17 01:22 .../lock...
...Jul 11 01:49 .../lock...
$ ~/.mozilla> uptime
09:41am  up 40 days  8:45...


Your "save for daily restarts" doesn't mean you re-boot your system each 
and every day ("up 40 days" = "how long the system has been running" 
(from manual), just that you re-start SM each day!!



Restarting above refers to closing one Gecko instance for the purpose of
backing it up without any of its files open, immediately followed by
starting it back up. it's a quick process, as each profile dir's cache
dir is always empty.


O.K., if you just re-boot/re-cycle, I'll give you 23.95/7, maybe, but 
not 24/7


And with a name like "Felix Miata", I was taking you as Spanish/Mexican, 
i.e. English not your first language, but then one of the other 
contributors here-abouts is "Jay Garcia" and I know he is U.S. of A.'ian 
(New Orleans), so, maybe, I should not be so quick to "ASSUME"!!


--
Daniel

User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20100101 
Firefox/21.0 SeaMonkey/2.18 Build identifier: 20130418192405


or

User agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:21.0) 
Gecko/20100101 Firefox/21.0 SeaMonkey/2.18 Build identifier: 20130403022815

___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SeaMonkey/2.19 on Linux nuked all messages in InBox and ALL folders underneath

[Paul B. Gallagher]

Chris Ilias wrote:


On 2013-07-17 12:14 PM, Paul B. Gallagher wrote:

Felix Miata wrote:


If it was up to me, delete would always mean delete rather than hide,
regardless of context. Delete that increases disk consumption by
even one bit is not deletion, it's a lie. Compaction would never be a
separate menu item or process.


The point of doing it this way is to make undo possible.


Are you assuming that is the reason, or do you have a source to cite?


Sorry, didn't realize I had strayed into academia. ;-)

I don't have a source, but it's the only theory that makes any sense. 
Why would a programmer or developer go to all the extra trouble of doing 
it this way when it would be much simpler and easier to simply do as 
Felix says? Only if there were some benefit. And the benefit I outlined 
is both obvious and desirable to most users.


--
War doesn't determine who's right, just who's left.
--
Paul B. Gallagher

___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SeaMonkey/2.19 on Linux nuked all messages in InBox and ALL folders underneath

[Felix Miata]

On 2013-07-17 17:51 (GMT-0400) Paul B. Gallagher composed:


Felix Miata wrote:



Delete means cancel, expunge or eradicate. It's been around a very very
long time. A hide operation that's reversible needs a different word
that does not connote increase available free space. Current delete
usage on a computer parallels misuse of megabyte/MB for 2^20 instead of
its original and still current meaning 10^6.



I suggest you read up on what "delete" means in a computer context. It's
been like this for several decades.


I suggest computer programmers stop the practice of stealing away the 
traditional meanings of words, particularly common words with no equally 
common synonyms, for instance, delete.


Some people still use DOS apps, because they are simple, reliable, and 
sensible. Those I use use the word delete to mean delete, not hide from view. 
There ought to be a way to in mature apps like web browsers to maintain 
consistency, like options to make words mean what the dictionaries have said 
that they mean since decades before semiconductors and PCs were invented.

--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SeaMonkey/2.19 on Linux nuked all messages in InBox and ALL folders underneath

[Ed Mullen]

Paul B. Gallagher wrote:

Felix Miata wrote:


On 2013-07-17 12:14 (GMT-0400) Paul B. Gallagher composed:


Felix Miata wrote:



If it was up to me, delete would always mean delete rather than hide,
regardless of context. Delete that increases disk consumption by
even one bit is not deletion, it's a lie. Compaction would never be a
separate menu item or process.



The point of doing it this way is to make undo possible. If all deletes
were permanent and irrevocable, the system would be very unforgiving and
not as user-friendly. I make enough mistakes that I prefer to spend a
couple of MB on my terabyte drive for CYA.


Delete means cancel, expunge or eradicate. It's been around a very very
long time. A hide operation that's reversible needs a different word
that does not connote increase available free space. Current delete
usage on a computer parallels misuse of megabyte/MB for 2^20 instead of
its original and still current meaning 10^6.

CYA is one of the things backups are for.


Do you make backups every 30 seconds? I don't, I run mine nightly. If I
make a mistake between 9 am and noon, I can only roll back to last
night's backup, not to where I was an hour ago.

I suggest you read up on what "delete" means in a computer context. It's
been like this for several decades. If your disk space is so tight that
you need to save a couple of megabytes this way, you need a bigger disk.
Otherwise, thank the developers and move on.



Not to mention how cheap hard drives are these days.  I hardly delete 
anything anymore.  In fact, I just make copies of it all.  No need to be 
selective about is saved.  Save it all, rotate it.



--
Ed Mullen
http://edmullen.net/
Why doesn't the glue stick to the inside of the bottle?
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SeaMonkey/2.19 on Linux nuked all messages in InBox and ALL folders underneath

[Chris Ilias]

On 2013-07-17 12:14 PM, Paul B. Gallagher wrote:

Felix Miata wrote:


If it was up to me, delete would always mean delete rather than hide,
regardless of context. Delete that increases disk consumption by
even one bit is not deletion, it's a lie. Compaction would never be a
separate menu item or process.


The point of doing it this way is to make undo possible.


Are you assuming that is the reason, or do you have a source to cite?

--
Chris Ilias 
Newsgroup moderator
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SeaMonkey/2.19 on Linux nuked all messages in InBox and ALL folders underneath

[Paul B. Gallagher]

Felix Miata wrote:


On 2013-07-17 12:14 (GMT-0400) Paul B. Gallagher composed:


Felix Miata wrote:



If it was up to me, delete would always mean delete rather than hide,
regardless of context. Delete that increases disk consumption by
even one bit is not deletion, it's a lie. Compaction would never be a
separate menu item or process.



The point of doing it this way is to make undo possible. If all deletes
were permanent and irrevocable, the system would be very unforgiving and
not as user-friendly. I make enough mistakes that I prefer to spend a
couple of MB on my terabyte drive for CYA.


Delete means cancel, expunge or eradicate. It's been around a very very
long time. A hide operation that's reversible needs a different word
that does not connote increase available free space. Current delete
usage on a computer parallels misuse of megabyte/MB for 2^20 instead of
its original and still current meaning 10^6.

CYA is one of the things backups are for.


Do you make backups every 30 seconds? I don't, I run mine nightly. If I 
make a mistake between 9 am and noon, I can only roll back to last 
night's backup, not to where I was an hour ago.


I suggest you read up on what "delete" means in a computer context. It's 
been like this for several decades. If your disk space is so tight that 
you need to save a couple of megabytes this way, you need a bigger disk. 
Otherwise, thank the developers and move on.


--
War doesn't determine who's right, just who's left.
--
Paul B. Gallagher
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SeaMonkey/2.19 on Linux nuked all messages in InBox and ALL folders underneath

[Felix Miata]

On 2013-07-17 12:14 (GMT-0400) Paul B. Gallagher composed:


Felix Miata wrote:



If it was up to me, delete would always mean delete rather than hide,
regardless of context. Delete that increases disk consumption by
even one bit is not deletion, it's a lie. Compaction would never be a
separate menu item or process.



The point of doing it this way is to make undo possible. If all deletes
were permanent and irrevocable, the system would be very unforgiving and
not as user-friendly. I make enough mistakes that I prefer to spend a
couple of MB on my terabyte drive for CYA.


Delete means cancel, expunge or eradicate. It's been around a very very long 
time. A hide operation that's reversible needs a different word that does not 
connote increase available free space. Current delete usage on a computer 
parallels misuse of megabyte/MB for 2^20 instead of its original and still 
current meaning 10^6.


CYA is one of the things backups are for.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SeaMonkey/2.19 on Linux nuked all messages in InBox and ALL folders underneath

[Paul B. Gallagher]

Felix Miata wrote:


If it was up to me, delete would always mean delete rather than hide,
regardless of context. Delete that increases disk consumption by
even one bit is not deletion, it's a lie. Compaction would never be a
separate menu item or process.


The point of doing it this way is to make undo possible. If all deletes 
were permanent and irrevocable, the system would be very unforgiving and 
not as user-friendly. I make enough mistakes that I prefer to spend a 
couple of MB on my terabyte drive for CYA.


--
War doesn't determine who's right, just who's left.
--
Paul B. Gallagher

___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SeaMonkey/2.19 on Linux nuked all messages in InBox and ALL folders underneath

[Felix Miata]

On 2013-07-17 20:02 (GMT+1000) Daniel composed:


Felix Miata wrote:



I compact more often than I empty trash. For
each and every empty trash (normally 20-30 minutes after midnight) I
immediately follow with compact. If I find some fool has emailed me
binaries, after deleting attached binaries I compact the folder they
showed up in before deleting the offending email.



Felix, it is my understanding that you are wasting your time compacting
your profile if you haven't, first, deleted the rubbish you want to get
rid of.


Looks to me like you need to reread what I wrote. What makes you think I ever 
compact without first deleting something?



Deleting an e-mail really just marks the e-mail for deletion,


Duh.


it is not
actually removed from your inbox file until it is marked for deletion
and then the file is compacted. If an e-mail is not first marked for
deletion, after the compaction it will remain (hidden) in your inbox file.


If it was up to me, delete would always mean delete rather than hide, 
regardless of context. Delete that increases disk consumption by even one bit 
is not deletion, it's a lie. Compaction would never be a separate menu item 
or process.



[re: Geckos] I keep 5 of them open spread across 8 virtual desktops
in the same DE 24/7, save for daily restarts and backups of the profile
used for email.



How can you say you have your DE up 24/7 when you then say you re-boot
daily?? Almost by definition, then, the most you have is up for 24 hours!


AU English must be more different from US than I thought, that or plenty of 
after dinner cocktails before reading newsgroups. :-p Again I think you need 
to reread.


$ ~/.mozilla> ll */lock
...Jul  9 14:19 .../lock...
...Jul  9 14:24 .../lock...
...Jul  9 13:58 .../lock...
...Jul 17 01:22 .../lock...
...Jul 11 01:49 .../lock...
$ ~/.mozilla> uptime
09:41am  up 40 days  8:45...

Restarting above refers to closing one Gecko instance for the purpose of 
backing it up without any of its files open, immediately followed by starting 
it back up. it's a quick process, as each profile dir's cache dir is always 
empty.

--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SeaMonkey/2.19 on Linux nuked all messages in InBox and ALL folders underneath

[Daniel]

Felix Miata wrote:

On 2013-07-16 10:02 (GMT-0400) Michael Lueck composed:


Felix Miata wrote:



Not a fix, just a suggestion for the future: Back up daily.



Well, I do weekly backups on Saturday... this was to be the last email
sent prior to weekly mailbox compaction, then backup.


Forgot another suggestion. I compact more often than I empty trash. For
each and every empty trash (normally 20-30 minutes after midnight) I
immediately follow with compact. If I find some fool has emailed me
binaries, after deleting attached binaries I compact the folder they
showed up in before deleting the offending email.


Felix, it is my understanding that you are wasting your time compacting 
your profile if you haven't, first, deleted the rubbish you want to get 
rid of.


Deleting an e-mail really just marks the e-mail for deletion, it is not 
actually removed from your inbox file until it is marked for deletion 
and then the file is compacted. If an e-mail is not first marked for 
deletion, after the compaction it will remain (hidden) in your inbox file.



I know of no way to gracefully exit Mozilla products via command line.
I leave SM up "all the time", though have to restart it periodically
due some blasted folder memory leak, disappearing child
folders. To mask that, I can open a new SM mail window instance and at
least the folders show up again. Sluggish folder open/close
performance requires a restart however.


I don't see any obvious signs of any Gecko leaking any significant
amount of memory. I keep 5 of them open spread across 8 virtual desktops
in the same DE 24/7, save for daily restarts and backups of the profile
used for email. Maybe your problem is confined to 64 bit, or maybe the
fault is in permissions or XFS or Ubuntu or its Pango or Gnome or
mushrooming disk space consumption by saving email with binaries
attached or 


How can you say you have your DE up 24/7 when you then say you re-boot 
daily?? Almost by definition, then, the most you have is up for 24 hours!


--
Daniel

User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20100101 
Firefox/21.0 SeaMonkey/2.18 Build identifier: 20130418192405


or

User agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:21.0) 
Gecko/20100101 Firefox/21.0 SeaMonkey/2.18 Build identifier: 20130403022815

___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SeaMonkey/2.19 on Linux nuked all messages in InBox and ALL folders underneath

[Felix Miata]

On 2013-07-16 10:02 (GMT-0400) Michael Lueck composed:


Felix Miata wrote:



Not a fix, just a suggestion for the future: Back up daily.



Well, I do weekly backups on Saturday... this was to be the last email sent 
prior to weekly mailbox compaction, then backup.


Forgot another suggestion. I compact more often than I empty trash. For each 
and every empty trash (normally 20-30 minutes after midnight) I immediately 
follow with compact. If I find some fool has emailed me binaries, after 
deleting attached binaries I compact the folder they showed up in before 
deleting the offending email.



I know of no way to gracefully exit Mozilla products via command line. I leave SM up 
"all the time", though have to restart it periodically due some blasted folder 
memory leak, disappearing child
folders. To mask that, I can open a new SM mail window instance and at least 
the folders show up again. Sluggish folder open/close performance requires a 
restart however.


I don't see any obvious signs of any Gecko leaking any significant amount of 
memory. I keep 5 of them open spread across 8 virtual desktops in the same DE 
24/7, save for daily restarts and backups of the profile used for email. 
Maybe your problem is confined to 64 bit, or maybe the fault is in 
permissions or XFS or Ubuntu or its Pango or Gnome or mushrooming disk space 
consumption by saving email with binaries attached or 



Using Linux, the only time I've needed to restore from backup is due to
disappearance of a folder due to an accidental drag.



Jah, I am suspecting I detected I "accidentally started to drag", realized what 
SM thought I meant, stopped, and it was too late. :-(


When I catch myself accidentally dragging, I drag the pointer outside the 
window or to an obviously illegal location before releasing any button.

--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SeaMonkey/2.19 on Linux nuked all messages in InBox and ALL folders underneath

[Michael Lueck]

Felix Miata wrote:

Not a fix, just a suggestion for the future: Back up daily.


Well, I do weekly backups on Saturday... this was to be the last email sent 
prior to weekly mailbox compaction, then backup.

I know of no way to gracefully exit Mozilla products via command line. I leave SM up "all the time", though have to restart it periodically due some blasted folder memory leak, disappearing child 
folders. To mask that, I can open a new SM mail window instance and at least the folders show up again. Sluggish folder open/close performance requires a restart however.


"Unable to expand a folder's subfolders without opening the folder first in a new 
email window"
https://bugzilla.mozilla.org/show_bug.cgi?id=593519

Anyway... for daily backups I could run them on the local filesystem, and not go through the compact... IF I could automate graceful exit/restart of SM. Suggestions to accomplish such? Then I could 
have the weekly manual backup remain to our server, run that after cleanup/compact.



Using Linux, the only time I've needed to restore from backup is due to
disappearance of a folder due to an accidental drag.


Jah, I am suspecting I detected I "accidentally started to drag", realized what 
SM thought I meant, stopped, and it was too late. :-(

Sincerely,

--
Michael Lueck
Lueck Data Systems
http://www.lueckdatasystems.com/
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SeaMonkey/2.19 on Linux nuked all messages in InBox and ALL folders underneath

[Felix Miata]

On 2013-07-13 18:26 (GMT-0400) Michael Lueck composed:


Suggestions other than roll that account back to my most recent profile backup?


Not a fix, just a suggestion for the future: Back up daily. I think that's 
the only way to prevent inexplicable failures. Using Linux, the only time 
I've needed to restore from backup is due to disappearance of a folder due to 
an accidental drag. I've been using Mozilla.org's 2.19 downloaded and 
unpacked manually since day of release announcement. I have several mail 
accounts, and several news servers configured. In browser I usually have no 
less than 30 tabs open, often many more.


32 bit openSUSE 11.4
KDE3
EXT3 /home


System configuration:
Ubuntu 12.04 x64
XFS filesystem
SeaMonkey via UbuntuZilla, so the official Mozilla binaries

--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SeaMonkey/2.19 on Linux nuked all messages in InBox and ALL folders underneath

[Michael Lueck]

A Williams wrote:


Have you found out what happened and how?  There was no step I could suggest 
that you had not tried anyway.



No I have not. Limping along with webmail access to the various accounts I use 
with SM.

--
Michael Lueck
Lueck Data Systems
http://www.lueckdatasystems.com/
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SeaMonkey/2.19 on Linux nuked all messages in InBox and ALL folders underneath

[Michael Lueck]

Bill Davidsen wrote:

Can you fall back to 2.17.1 and try the rebuild option again?


What is the silver bullet about that particular build of SM?

I suppose I could force the UbuntuZilla package for that version to get back to 
that version.

Sincerely,

--
Michael Lueck
Lueck Data Systems
http://www.lueckdatasystems.com/
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SeaMonkey/2.19 on Linux nuked all messages in InBox and ALL folders underneath

[Bill Davidsen]

Michael Lueck wrote:

Greetings,

I had a most odd / scary thing happen this morning. I was sending an email via a
SM POP account with a few MB of files attached to it. I remember accidentally
clicking / doing something while it was sending via my SMTP (TLS) connection...
and POOF that account's InBox went blank, and ALL sub-folders under the InBox
have vanished. No pop-up message box what so ever was seen.

There is no trace of them in the profile filesystem. This account's Inbox.sbd is
completely empty.

At the command line I changed up to the Mail directory and did "find | grep foo"
where Foo is the name of folders which existing under that account's InBox.
(Being careful to observe PrettyCase since this is a CaSe sEnSiTiVe filesystem I
am dealing with.) NO TRACE of where the folders went.

The files for the InBox are as follows:

-rw---  1 mdlueck mdlueck 46285982 Jul 13 09:45 Inbox
-rw-rw-r--  1 mdlueck mdlueck 2146 Jul 13 10:19 Inbox.msf
-rw-rw-r--  1 mdlueck mdlueck67775 Jul 13 09:50 Inbox.ORIG.msf

I renamed off the folder index .msf file and rebuilt that folder's index. Though
the Inbox data file has messages in it, they do not show up.

Suggestions other than roll that account back to my most recent profile backup?

Can you fall back to 2.17.1 and try the rebuild option again? That is wildly 
odd, and whatever you do, don't compact your folders or you really will lose 
everything. From the file sizes I'm guessing that you somehow marked those 
messages but they're still in the message file.


You might be able to run the file through a tool like awk or sed and reset the 
flags which say the message is deleted. I remember doing that for some other 
reason once, renamed the Inbox, ran it through awk, saved the output as Inbox 
and rebuilt the index. You might scan the file with less or similar and see that 
it has what you are missing.

System configuration:
Ubuntu 12.04 x64
XFS filesystem
SeaMonkey via UbuntuZilla, so the official Mozilla binaries

Sincerely,




--
Bill Davidsen 
  We are not out of the woods yet, but we know the direction and have
taken the first step. The steps are many, but finite in number, and if
we persevere we will reach our destination.  -me, 2010


___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SeaMonkey/2.19 on Linux nuked all messages in InBox and ALL folders underneath

[A Williams]

Michael Lueck wrote:

Greetings,

I had a most odd / scary thing happen this morning. I was sending an
email via a SM POP account with a few MB of files attached to it. I
remember accidentally clicking / doing something while it was sending
via my SMTP (TLS) connection... and POOF that account's InBox went
blank, and ALL sub-folders under the InBox have vanished. No pop-up
message box what so ever was seen.

There is no trace of them in the profile filesystem. This account's
Inbox.sbd is completely empty.

At the command line I changed up to the Mail directory and did "find |
grep foo" where Foo is the name of folders which existing under that
account's InBox. (Being careful to observe PrettyCase since this is a
CaSe sEnSiTiVe filesystem I am dealing with.) NO TRACE of where the
folders went.

The files for the InBox are as follows:

-rw---  1 mdlueck mdlueck 46285982 Jul 13 09:45 Inbox
-rw-rw-r--  1 mdlueck mdlueck 2146 Jul 13 10:19 Inbox.msf
-rw-rw-r--  1 mdlueck mdlueck67775 Jul 13 09:50 Inbox.ORIG.msf

I renamed off the folder index .msf file and rebuilt that folder's
index. Though the Inbox data file has messages in it, they do not show up.

Suggestions other than roll that account back to my most recent profile
backup?

System configuration:
Ubuntu 12.04 x64
XFS filesystem
SeaMonkey via UbuntuZilla, so the official Mozilla binaries

Sincerely,



Have you found out what happened and how?  There was no step I could 
suggest that you had not tried anyway.

___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

SeaMonkey/2.19 on Linux nuked all messages in InBox and ALL folders underneath

[Michael Lueck]

Greetings,

I had a most odd / scary thing happen this morning. I was sending an email via a SM POP account with a few MB of files attached to it. I remember accidentally clicking / doing something while it was 
sending via my SMTP (TLS) connection... and POOF that account's InBox went blank, and ALL sub-folders under the InBox have vanished. No pop-up message box what so ever was seen.


There is no trace of them in the profile filesystem. This account's Inbox.sbd 
is completely empty.

At the command line I changed up to the Mail directory and did "find | grep foo" where Foo is the name of folders which existing under that account's InBox. (Being careful to observe PrettyCase since 
this is a CaSe sEnSiTiVe filesystem I am dealing with.) NO TRACE of where the folders went.


The files for the InBox are as follows:

-rw---  1 mdlueck mdlueck 46285982 Jul 13 09:45 Inbox
-rw-rw-r--  1 mdlueck mdlueck 2146 Jul 13 10:19 Inbox.msf
-rw-rw-r--  1 mdlueck mdlueck67775 Jul 13 09:50 Inbox.ORIG.msf

I renamed off the folder index .msf file and rebuilt that folder's index. 
Though the Inbox data file has messages in it, they do not show up.

Suggestions other than roll that account back to my most recent profile backup?

System configuration:
Ubuntu 12.04 x64
XFS filesystem
SeaMonkey via UbuntuZilla, so the official Mozilla binaries

Sincerely,

--
Michael Lueck
Lueck Data Systems
http://www.lueckdatasystems.com/
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey