Re: Very disturbing feature in icedove
Dave Sherohman wrote:
On Wed, Feb 14, 2007 at 02:30:48PM -0500, Daniel B. wrote:
Dave Sherohman wrote:
On Sat, Feb 10, 2007 at 12:36:55PM -0500, Roberto C. Sanchez wrote:
I was complaining solely about the use of "compact" to mean "delete".
Are you confusing the logical level (what the user almost always deals
with) with the physical level?
I would instead say that the Netscape/IceDove/Mozilla/SeaMonkey developers
are forcing the end user to deal with the details of the physical layer
rather than allowing users to exist, as they normally do, in the logical
realm.
Yes, that seems true.
Of course, sometimes users have to deal with the physical layer. I
guess the question is how much (how much is reasonable).
If you delete files from a disk (past any temporary Trash folder as on
Windows), it's true that you don't have to deal with really deleting
the files in the sense of making the space available for other files,
but you _do_ have to deal with really erasing the data (overwriting the
sectors) if you want to make sure the data is really gone.
The question in the current case is probably whether the user should
control when Seamonkey takes the time to compact folder since the
physical-layer aspect of the time it takes to re-write the files
(presumably) can't be hidden from the user (within the constraint of
using a standard mail-file format and reducing risk of corruption
from crashes or power failures).
At the logical level, the messages are already deleted (from the folder).
There is no way to get them back (from th[e] folder from which they're
deleted) going through the tool (Seamonkey).
If the tool does not provide a means to undelete messages, then I also
find the decision to not make permanent deletion (either when the user
changes folders or exits the program; it doesn't need to be immediate
for reasons which have been repeatedly discussed in this thread already)
a default action to be questionable at best. If you can't undelete it,
then why keep it around?
It might be part of the physical layer that the user does have to deal
with: reliability.
It's not so much that deleted messages _are_ explicitly _kept_ around;
it's that they are _not_ _deleted_ right away. That, of course, is
because trying to delete a message right away by re-arranging the file
(given the current file format, or course) would increase the risk of a
corrupted file in case of crash or power failure during the re-arranging
(and because immediately copying all non-deleted messages to a new file
when a message is deleted would be too slow).
But yes, since (non-hacker) users can't recover messages deleted from
a folder, it would be good if users didn't have to deal with it.
However, given the time it takes to compact a large folder, I don't
know if automatically compacting on, say, exit would be good.
Maybe Seamonkey/etc. should default to compacting on exit or some other
reasonable time, but display a "why is Seamonkey compacting" message or
button that explains what it is doing and points the user toward the
appropriate settings.
...>
But that's the same as deleting a file: Deleting a file tells the file
system to forget about remembering the data, but it doesn't usually
overwrite the data, so it or pieces of it are still on the disk unless
you perform some other operation to actually remove (overwrite) it.
Not really a very good analogy, as the file system will reuse the disk
space without requiring any additional action ('compact', 'purge',
'expunge', whatever) after the file has been deleted.
How is it not a perfect analogy? I didn't talk about the physical aspect
of re-using the space, which the file system _does_ handle for the user;
I talked about the physical aspect of making sure your data was erased,
which users have to be aware of (whether or not they should have to be).
Daniel
Reply to: