How do we reconcile changes to the Inbox that were not made by msgvault?

[larray]

I found an interesting item - not really 'broken' but I am curious how I might go about cleaning up the entry on my msgvault side.

I found a mail item in my drafts that had a 22MB attachment in it thanks to msgvault:

I went into Gmail and altered the Subject with the express intent of finding out how that would impact msgvault, and it created a 'duplicate' record (engineering wise I know it is a new record - the time/date changed and the old 'draft' no longer exists)

Which presents an interesting conundrum - how to handle items that are no longer in Gmail that weren't deleted by msgvault?

[wesm]

When you delete e-mails in Gmail using msgvault, they are marked as deleted by msgvault in the database. Syncing your deletions back to msgvault is a bit of an open question. I'm genuinely interested in documenting all the workflows that people think would be useful so we can try to implement them and make it clear in the tool what does what (so that we avoid footguns)

The initial purpose of this tool is to be an archive of all the mail that you have received and in general not to delete mail from msgvault. I plan to add the ability to delete email from msgvault AND gmail, but the intended workflow for most "small" email is to delete the remote copy and keep the local one. But I can understand why you might want to delete large attachments that you don't care about and don't want to drag around for the rest of your life.

[larray]

Exactly - I mean I COULD dump (or even archive) the initial DB after I've done my cleanups in either msgvault or Gmail - then perform a resync / fresh sync and manage from msgvault going forward. But the idea that perhaps I've deleted something in Gmail between the time I took my first snapshot (or even while the first sync is occurring) and to the point where I use msgbox to do the deep analysis leaves a gap (hopefully small) of items that get orphaned in msgbox. Then it gets really icky on which is the 'official' record. :)

[wesm]

The easy way to look at it is that the trip to msgvault is a "one-way journey" for the emails so once they are in msgvault they are "safe" and you can scrub gmail or whatever mail provider you use without worrying about losing data.

I do not think that having deletions from Gmail sync back to msgvault makes sense -- if you want to delete stuff from msgvault, you will soon be able to do that, but it may be a few days until I can work through the details.

[sinnet3000]

I do not think that having deletions from Gmail sync back to msgvault makes sense -- if you want to delete stuff from msgvault, you will soon be able to do that, but it may be a few days until I can work through the details.

Completely agree. It’s a vault, not another Gmail client, so mirroring deletions back from Gmail doesn’t really make sense. That said, I’ve definitely run into cases where there are things I don’t want to keep in the vault forever, so having a clean way to remove them there still matters.

[trel]

perhaps during/after a sync... msgvault can make obvious to the user items that it has that were no longer found on the source side.

So, not an automatic 'syncing of the deleted item', but rather, showing the user that it was noticed... and if the user wants to manage/delete the 'extra' msgvault entry, then that's a separate bit of functionality.

[larray]

Frankly I love this idea - it was really a way to reconcile the delta between what was "In Gmail" and what was orphaned in MsgVault. There may be items I DO want to keep in perpetuity in the MsgVault, there may be others that once the Gmail box is triaged (I go on a wild hair one day and nuke all the alerts from Google that my Inbox is out of space) it makes sense to puge them from MsgVault.

Having a way to identify the deltas would IMHO be really handy.