[Bug 2920] Discussion about deleting attachments
Matt Coughlin
I'm having to step aside from the effort on bug 2920; just don't have
the energy or ability for a task of this scale and complexity, even
working at a very gradual pace. Unable to proceed past the initial
progress of initiating and moderating design discussions.
If it's of help to anyone, here's an rough overview of how to delete
attachments by hand:
Mozilla: Deleting Attachments from a Message by Hand
----------------------------------------------------
* Run Mozilla.
* Note the name of the mailbox the message is in (i.e. "Inbox").
* Note some text info that's unique to the message, so that the message
can be easily located via a search in a text editor - perhaps the
subject of the message, or part of the body of the message (i.e.
"Greetings from Antarctica").
* Note the location of the mailboxes for the relevant mail account. To
find the location, select "Edit | Mail & Newsgroups Account
Settings...", and for the relevant mail account select "Server
Settings"; the location is specified in the "Local directory" edit box.
* Close Mozilla.
* Browse to the location of the mailboxes.
* Delete the .msf file for the relevant mailbox (i.e. "Inbox.msf").
This is the index file; Mozilla will recreate it from scratch if it's
not present. After the mailbox has been edited by hand, the old index
would no longer be valid anyways.
* Make a copy of the mailbox file (i.e. "Inbox"), in a different
directory, just to be safe.
* Open the mailbox file (i.e. "Inbox") in a text editor, one that does
not force hard-wrapping of long lines of text.
* Before editing the mailbox file, look at a few sample messages to gain
some familiarity with the mbox format, in particular with how
attachments are distinctly separated from the rest of the message.
Compare a message with no attachments to a message with 1 attachment,
and to a message with 2 or more attachments.
* If the basics of how attachments are specified in a message does not
become somewhat obvious, it's probably best to stop at this point and
not attempt to edit the message(s). Without at least a minimal
understanding of the layout of an mbox message, making changes to the
mailbox may cause the file to become corrupted - if the changes are made
improperly.
* Delete the relevant attachment(s) from the appropriate message(s).
* Save and close the mailbox file.
* Run Mozilla. A new index file (.msf) will automatically be created
for the mailbox.
* View the message(s) in Mozilla to verify that the attachment(s) have
been deleted, and that in all other respects the message(s) are still
valid and viewable.
--
Matt Coughlin
d...@sp4m-less.forestpath.org
<remove "sp4mless_" from the e-mail address to reply>
Eric Belhaire
mailer (http://www.mutt.org).
It is at least available in Unix/Linux and cygwin in Windows.
It does not seem that what is done by mutt is so difficult to implement.
Sincerely,
Eric
David Fraser
rather than just implementing it. Doing it the 'wrong way' (from some
RFC's point of view) for now is better than not doing it at all. Not to
raise another flame war, but because once something is there it can be
changed and improved...
Daivd
Karel Miklav
couldn't believe. But not being able to delete attachments, as I
discovered this morning is a feature that makes me look back.
I do not understand what is so hard about deleting an attachment; if
headers would have to be changed or anything that's ok with me. Please
make my day :)
Regards,
Karel Miklav
Karel Miklav
> I'm having to step aside from the effort on bug 2920; just don't have
> the energy or ability for a task of this scale and complexity, even
> working at a very gradual pace. Unable to proceed past the initial
> progress of initiating and moderating design discussions.
>
>
> If it's of help to anyone, here's an rough overview of how to delete
> attachments by hand:
Ok, I got it. Now if it's of your interest I could write a logic to do
it, if you are able to integrate that in the user interface.
Regards, Karel Miklav
David Fraser
Mozilla code. Seems to me most of the people commenting here don't know
the code well. Neither do I.
I have posted some comments on the bug recently on how to implement a
simple Delete Attachment method (comparing to draft messages etc) - are
any of the mail developers reading this, am I on the right or the wrong
track?
David
Matt Coughlin
design approaches:
I.
After the user selects which attachment(s) to delete in the current
message...
* Uniquely identify which attachment(s) in which message in which
folder are to be deleted.
* Search through the physical mail folder (the file) for the message
in question, using the index info (the info in the related .msf file,
which may already have been loaded into some data structure in memory)
as needed to help find the message.
* Copy the message to the physical end of the mail folder, section by
section. For each attachment in the message that has been selected for
deletion, supply the revised attachment info or simply omit the
attachment data altogether.
* Mark the original copy of the message as having been deleted
(altering the main file and the index file as needed).
* If needed, request that Mozilla recreate the index file for the mail
folder (if sufficient changes to the index were not made in the previous
step).
* Reload the message in the message window (if the message is
currently being displayed).
The main intention here is to bypass as much as possible of the existing
code for manipulating and viewing messages, such that it may be possible
to write relatively simple and self-contained code for deleting
attachments, without having to add a few lines of code to virtually
every class used by Mozilla (an exageration, of course). Whether it
would be advantageous to write self-contained code like this, I don't
know. I was motivated largely by not knowing being able to make much
sense out of much of the code base, figuring that the less I were to
mess with the existing code, the better.
II.
One variation on this is, assuming the message is smaller in size
after the attachment(s) are deleted, is to read the whole message into a
buffer, and overwrite the altered message to the same location in the
file. I'm not sure if this is practical or possible; there'd be some
dead space at the end of the altered message that would need to be dealt
with.
The advantage here is that the size of the file isn't increasing
in size every time an attachment is deleted (consider if someone goes
through and deletes attachments from dozens or hundreds of messages).
The disadvantage is that this somewhat rules out the option of an "undo"
operation.
III.
Another variation, one which might make more sense if attachments were
being deleted from a large number of messages (say, if there were a
filter option for deleting specified attachments from a folder), is to
mimic the way a folder is compacted. But instead of removing
already-deleted messages, alter the messages that have attachments
selected for deletion. Code similar to compacting a folder could be
written, or it might be possible to piggy-back on top of the existing
code for compacting folders and branch off at times, to perform the
alternate functionality for deleting attachments rather than getting rid
of already-deleted messages. If not done carefully though, the
"piggy-backing" approach might corrupt the functionality for compacting
folders.
The advantage here is that if large numbers of attachments are going to
be deleted, it can be done in a single large but relatively quick
operation, without the possibility of the mailbox file growing
excessively in size, and it may also be possible to avoid having to deal
with most of the existing codebase for viewing and manipulating messages
(if that is in fact a good thing). The disadvantage is that it somewhat
rules out the option of an "undo" operation (unless the original mailbox
file is stored temporarily), and it might be unreasonably slow for
deleting a small number of attachments. This approach would lend itself
very well to deletion of a large number of attachments, say perhaps
through a user-specified filter.
Bear in mind that I was able to discern very little about the actual
design of Mozilla. It's for good reason that I'm talking in high-level,
non-detailed terms - because I don't know what the heck the source code
is actually doing hehe. As such, some of the aforementioned design
approaches might be incompatible with the existing design of Mozilla.
It's good to see the increased level of activity about this bug in
recent days. I can't implement this bug myself, but I'll at least try
to relay some of the things I was considering, if it looks like it might
be helpful.
Matt
Matt Coughlin
> rather than just implementing it. Doing it the 'wrong way' (from some
> RFC's point of view) for now is better than not doing it at all. Not to
> raise another flame war, but because once something is there it can be
> changed and improved...
The main reason that I recommend in favor of first resolving the issue
of what's acceptable, before proceeding heavily into the design and
implementation, is basically this: Otherwise someone might put a great
deal of time and effort into making a patch, and then find that it's
inherently unacceptable to the reviewers, for some reason of design
incompatibility or violation of standards. And this seems to be a very
controversial / sensitive bug, one that may be much more likely to be
held to very careful standards of review.
It just seems reasonable to find out first if an approach is
architecturally acceptable. After a few weeks of working on this bug, I
quickly decided that I wouldn't spend another second on detailed design
or implementation until I could first find out what sort of basic
approach would be acceptable. It's just too big a risk of time and
effort otherwise. I might say otherwise if this was a relatively quick
and easy patch to make.
Matt Coughlin
attachments, one that is relatively isolated from the rest of the source
code, is because the more I took a look at the Mozilla mail client, the
more I got the feeling that the altering of existing messages (short of
changing a message to a draft, via "Edit as New"), just isn't something
that was intended to be supported by the existing architecture and
design of Mozilla. I don't know that for certain, but I got that
feeling pretty consistently, and I didn't come across anything that
suggested otherwise.
Worst case, it might be necessary to create sort of a separate branch of
functionality for anything relating to altering existing messages, like
a set of separate classes for such actions, with nearly no interaction
between the new classes and the existing codebase. As in, at some point
in the existing code, you say, "Okay, I need to go alter this message,
so I'm going to go into the new classes now, and I'll finish all of the
work before coming back (possibly calling a few functions in the
existing code base if needed, like for recreating the index for a mailbox)."
I suspect there may be some major maintenance risks with separating the
code in this manner, like the two sets of classes getting out of synch
when future changes get made. Admittedly, it feels like a clumsy
solution (though sometimes a certain level of clumsiness is acceptable).
The alternative is to work the functionality in cleanly and
consistently with the existing source code, which requires a thorough
understanding of the source code, and, perhaps more significantly, may
require a sizeable reworking of the existing architecture and design if
in fact there's nothing in place already to allow the altering of
existing messages.
With any luck, maybe the existing architecture and design would
accomodate such new functionality without much trouble. If so, that
would certainly simplify this situation a lot. Then it would just be a
matter of undertanding the relevant part of the existing code base well
enough to know how to add in the changes, with no re-architecting or
re-designing required.
David Fraser
and there hasn't been a simple patch! If anyone can produce one, no
matter how simple and likely to be rejected, at least attach it to the
bug and then the process can continue from there. We at least need the
ability to be able to remove/replace an attachment in a normal (not
draft/editable) message. The actual decisions about exactly how that is
to be done are important, but are completely academic until there's an
actual patch. The reviewers aren't going to even give their opinion if
all we do is discuss the possibilities.
Also, the different possibilities of what's acceptable aren't actually
that different in terms of implementation. Most of them consist of
adding a message header or a replacement MIME part. Once the actual code
to do the basic change is available in the form of a patch, I suspect it
would be quite easy to change. Anyway that's refactoring theory for you.
Even if someone does a quick and easy patch and it gets rejected, that's
work for someone else to take and use - and it seems the majority of
people that are interested don't actually know their way around the code
well enough to start, so any head start would be useful.
David
David Fraser
> The reason I was leaning so much towards a self-contained way to delete
> attachments, one that is relatively isolated from the rest of the source
> code, is because the more I took a look at the Mozilla mail client, the
> more I got the feeling that the altering of existing messages (short of
> changing a message to a draft, via "Edit as New"), just isn't something
> that was intended to be supported by the existing architecture and
> design of Mozilla. I don't know that for certain, but I got that
> feeling pretty consistently, and I didn't come across anything that
> suggested otherwise.
>
the code for editing a draft irrelevant, rather we just need to find the
appropriate parts to copy and bring it over to the standard
message-handling bit. Even a simple "Edit Message" functionality that
differs from "Edit as New" by not changing headers and dates would be a
step in the right direction. It needn't go into the Mozilla code, but
would help us work out what to do...
currently non-editable messages ... we can start with a whole chunk of
code copied from the editable messages areas, then trim it down so that
only the needed functionality is there. Then it'll be clean!
Karel Miklav
a poorly designed application trying to make a nice user interface. On a
second thaught, I'll rather delete my attachments by hand than patch the
patchmaker forever.
Gee, it's a cruel world. If I only had 284 lives :))
Regards, Karel Miklav
Matt Coughlin
> and there hasn't been a simple patch! If anyone can produce one, no
> matter how simple and likely to be rejected, at least attach it to the
> bug and then the process can continue from there. We at least need the
> ability to be able to remove/replace an attachment in a normal (not
> draft/editable) message. The actual decisions about exactly how that is
> to be done are important, but are completely academic until there's an
> actual patch. The reviewers aren't going to even give their opinion if
> all we do is discuss the possibilities.
>
> Also, the different possibilities of what's acceptable aren't actually
> that different in terms of implementation. Most of them consist of
> adding a message header or a replacement MIME part. Once the actual code
> to do the basic change is available in the form of a patch, I suspect it
> would be quite easy to change. Anyway that's refactoring theory for you.
>
> Even if someone does a quick and easy patch and it gets rejected, that's
> work for someone else to take and use - and it seems the majority of
> people that are interested don't actually know their way around the code
> well enough to start, so any head start would be useful.
Okay, those are some good points. I'd be all for a quick and easy patch
even if it does get rejected, so long as there's some progress in the
right direction.
I see two ways that a patch might be possible:
I. Someone with much experience with the relevant code base puts
together a prototype patch, acting largely on their own.
II. The community sorts out, as much as possible, the design details of
what would be acceptable and reasonable, clearly identifying (in
layman's terms) what sort of programming work would have to be done.
Someone with limited experience with the code base then puts together a
patch largely based on what the community established.
The problem here, is that such a person for option (I) might not be
available, and so far, even option (II) hasn't turned up tangible
results. As far as option (II) goes, either the design details haven't
been thrashed out enough by the community yet, or else no one with even
sufficient limited experience with the code base has turned up. I've
tried tackling the relevant code base myself, and found that the
complexity was more than I could manage
At this point I'm trying to just chip away at the problem a little at a
time, in the hope of finding anything that might help even a little, as
well as exposing potential show-stoppers that might lead to dead-ends.
If there's a reasonable path to a solution and someone is able to carry
it out themselves or see to it that someone else does, then please, by
all means, pursue whatever looks doable. I'd encourage anyone that
feels able to put together a patch, of whatever sort, to do so.
Matt Coughlin
> currently non-editable messages ... we can start with a whole chunk of
> code copied from the editable messages areas, then trim it down so that
> only the needed functionality is there. Then it'll be clean!
I wonder if there's a feasible way to do this where not too much of the
same functionality winds up existing in two separate places in the code
base (redundancy of code). Redundancy can be a maintenance nightmare;
on the other hand, creating a new class for the common code and
reworking the "Edit as New" code to make use of it, might be a bit
tricky (it'd raise the degree of difficulty a good bit).
I suppose even redundant code might still be a step in the right
direction, especially if someone was able to put it together with an eye
towards eventually combining it with the "Edit as New" code into a new
class (at some later point).
This also raises the question of whether "two steps forward, one step
back" is an acceptable approach to take (in this case, "one step back"
being the redundancy of code). There are probably some pretty strong
arguments against the "two steps forward, one step back" approach in
general, in terms of the long-term maintainability of a code base. I
suspect that this approach is tolerated much less in open-source
environments than it is in proprietary ones (due to peer review). Maybe
in this particular case, there's enough of a demand for it to be
justifiable, at least in the short term.
For most of the issues being discussed for bug 2920, I don't have the
experience or the savvy to do more than just raise the questions as
clearly as possible, in the hopes that others will be able to thrash it
out and figure out what would be best. I'm also still new to Mozilla
and open-source development, so I'm trying to get the hang of this whole
development process as I go (with plenty of stumbles along the way).
Matt Coughlin
I can relate to some of those feelings ;-) (though I think it may be
more a case of over-engineering). Still, at the very least, I think
it'd be reasonable, and maybe pretty easy, to make a separate utility,
that would be a heck of a lot easier (especially for the non-techies)
than deleting attachments by hand.
Just think about the advantages of a separate utility: not having to
deal with the existing code base; not having to deal with the exhausting
process of formal standards compliance; it wouldn't take nearly as much
programming experience or any familiarity with the code base, and it
could be done in a variety of languages as either a console or a GUI app.
Karel Miklav
this hand-editing gets...
Be well,
Karel Miklav
Matt Coughlin
> this hand-editing gets...
There's at least one existing Perl script that someone put together,
which was posted to bug 2920 as an attachment. This particular script
is still experimental.
The Perl script can be found at:
http://bugzilla.mozilla.org/attachment.cgi?id=112499&action=view
Neil
> If it's of help to anyone, here's an rough overview of how to delete
> attachments by hand:
Just to upset everybody, this of course assumes that your message is
stored locally, and not on an IMAP server; anyone thinking of coding
this had better remember us too :-P
--
Warning: May contain traces of nuts.