Ben Bucksch wrote: > Yes, but that's all but trivial. > > You have to create a new message, that has to have the exact same > content than the original one, but the part of the attachment has to be > new. It has to have some non-specified content. > (So far, that's also needed to delete an attachment.) > You have to save the filename. Then, you need to modify the message > viewer to show and open the attachment as saved file. Then, you'd need > to modify the move/copy mail function to adjust the pathname. This has > to work for drag&drop in the 3pane, the File button, the Search window, > filtering etc..
I know Eudora simply uses an absolute file path link to an attachment, thus making portability a good bit more complex. Initially I was thinking that a relative link might address this, but I do see your point. That does leave the scenario I'm proposing to either constantly be updating the link location to remain relative, or to use absolute links. The second of course killing portability. Couple of questions on the subject of what all goes on with the message filing though. Isn't there a single routine that's called to update both the source and destination mbox files? I would have thought that the same code would be used for the actual manipulation regardless of the means in which the user made the move. >From what little C I'm able to read, this would seem to reside within the "movemail.c" file using the fe_MoveMail() function. The bulk of the decoding code seems to be located within functions of "mimehdrs.cpp", where a fair amount of mbox manipulation appears to be going on. I am not a C kinda person, so I'm probably mistaking some of these references. > If there's a bug in the attachment removal, you'd have a critical > dataloss bug that is affecting all users. Very true. Could be just as true about any functioning writing to or reading from the mbox files. > This is assuming we know about all the issues already. > > If you ask me, the risk of implementing this is higher than that of your > AV scenario. Perhaps, but that doesn't address how to make sure that them AV apps don't muck with Moz's mbox files. We know that at very least Symantec's glitch is reproducable, and have strong suspicions concerning InnoculateIT. Ah well, I'm off for a Saturday evening somewhere in deepest darkest Santa Monica, or so I'm told. Maybe somewhere along the line one of us might manage an alternative a bit more acceptable to all. Later on, -- "Outside of a dog, a book is man's best friend. Inside of a dog, it's too dark to read." - Groucho Marx
