How to select destination location when archiving emails?

Hi there,
I’ve been a user of DT Pro for many years.
I recently upgraded to DT 3.

I see the interface has some wonderful improvements. Included in that is the sidebar being the location for interacting with the Import Email tools.

I have a database specifically for archived emails. I have perhaps 7 emails accounts archived in there. The folder structure DT created is something like.
— Emails > Apple Mail > “Name of Account”

I recall that in the past (DT2) when I updated my email archive it would add all the emails to the relevant (and existing) folder in my email archive database. I assume I was given the chance to select the destination database or even perhaps database and folder, whilst doing the archive procedure, and that was how my existing archive would get appended to with new emails.

But when I did the import using the new interface, I didn’t appear to have any way to choose the archive destination. And they ended up being archived into :: Globals — Inboxes > Emails > Apple Mail > “Account Name”.

Obviously that’s not where I want them. What’s more, dragging them over to where I want them brings up a progress indicator that they are being moved, yet after the move operation is complete, the emails are still in the wrong location.

I should mention I have the latest DT Mail plug-in installed.

Would someone kindly explain where I am going wrong?

Thanks so much.

Jonathan

1 Like

There certainly is a way to choose the destination database. It’s the Destination dropdown on the upper right as noted in the Help > Documentation > Windows > Sidebar: Email

  • Import lets you choose the database and group but doesn’t preserve the mailbox structure.
  • Archive Mailbox lets you choose the database but emails will be archived into the Emails group at the root of the database chosen in the Destination.

PS: I’m adding a little more clarifying language to this line item for the next release. Thanks for your patience and understanding.

1 Like

Great. Thank you Bluefrog.

You’re right … I didn’t see that drop down.

Now that I’ve mistakenly archived all emails since my previous archive round into the wrong location, what do you suggest? For some reason dragging them across didn’t seem to work, despite the progress indicator showing it was moving thousands of emails.

Is it best to just delete the wrongly located archive, and then archive them again, and using the date range to make sure I get those back to my last successful archive? Normally I just tell it to archive everything, and to ignore previously archived emails. But I gather that’s no longer an option, since I archived them already (to the wrong place).

Cheers,

Jonathan

1 Like

Oh my. Now that I do see it, I can’t believe I didn’t see it before! It’s pretty obvious.

:wink:
No worries! I wrote the documentation and live in the app so it’s a little more obvious to me :slight_smile:

Is anything reported in Window > Log?

First post, and my apologies for reopening this after more than a year - but I’ve ended up in a sticky situation that is more or less described by this thread.

  1. I created an archive of an Apple Mail email account a few years back.

  2. That email account is being deactivated tonight, and today I realised I’d not taken an archive in the last few years. So I happily set DevonThink to work - it took several hours due to the amount of data.

Unfortunately I didn’t pay enough attention to the 'Destination" field, so I now have 50,000 emails in a Emails → Apple Mail → AccountName group within my global Inbox - and not within the “Mail Archive” database which was the only database I had open.

An attempt to move the emails into this folder failed (after a long time beachballing) because of duplicate UUIDs - which to be fair is warned about in the “In & Out: Archiving Mail” help article:

This means you can’t import the same message into a database more than once, as that would result in more than one file having the same UUID. This will be shown in DEVONthink’s Window > Log. It can also cause issues when moving messages between databases. If you already imported messages into a database and forgot you did, trying to move the same email into it will fail.

The help article does talk about using Replicants, but I don’t think this meets my goal here - which is to have a single Mail Archive database.

The obvious answer would be simply to run the import again - but given the amount of time it took to import (4+ hours) and the amount of time I have left until the account expires (1 hour) this isn’t going to work, and I’d worry about database corruption - or simply unclear, inconsistent data - if interrupted half way through.

Any advice would be gratefully appreciated: given where I now am, is there any way of merging the Mail data that’s currently in the Global Inbox with my Mail Archive database (i.e. discarding duplicate UUIDs)? Worst case scenario I guess I could live with a second Mail Archive database for this account, but that’s not ideal.

Thanks!

A brief update: unfortunately I didn’t work out a solution to my specific question, of moving these from the Global inbox to an existing database, so can’t advise on that.

However, I was lucky in that the advertised cut off for my account was not the actual cutoff, and I had a further 10 or so hours - so I just ran the import again, and made sure the ‘destination’ field was selected.

I realise there may be a technical limitation associated with UUIDs that prevents the ‘merging’ of newly imported mail in one place (the inbox) with another (a database), but I wonder if this might be a feature request in future: if you try to merge things with duplicate UUIDs such as this, offer the option of checking the actual content (maybe via a checksum) of each of the two, and - with an appropriate warning of the possibility of data loss etc - offer to merge while removing duplicates.

When it comes to importing emails, there is no need to use a checksum. An email will have the same UUID no matter what. If a duplicate UUID is reported and you’re importing emails, there is no question the email already exists is the import destination database.