joeyates / imap-backup

Backup and Migrate IMAP Email Accounts
MIT License
1.33k stars 74 forks source link

imap-backup creates IMAP.$numbers.imap file #116

Closed damnms closed 2 years ago

damnms commented 2 years ago

i guess i messed up a bit of the backup and let the backup run twice so imap-backup created INBOX.249872498.imap and .mbox (the numbers are different)

I let imap-backup restore run but it did not restore the INBOX, so i renamed INBOX.$numbers to INBOX.imap and .mbox, but still, the restore does not upload the emails and it creates again the INBOX.$numbers.mbox /.imap any idea?

damnms commented 2 years ago

guess i found the problem

S: RUBY0039 OK Search completed (0.001 + 0.020 secs). D, [2022-02-24T11:05:29.757609 #24926] DEBUG -- : There's already a 'INBOX' folder with emails C: RUBY0040 EXAMINE INBOX S: OK [CLOSED] Previous mailbox closed. S: FLAGS (\Answered \Flagged \Deleted \Seen \Draft) S: OK [PERMANENTFLAGS ()] Read-only mailbox. S: 2 EXISTS S: 0 RECENT S: OK [UNSEEN 1] First unseen. S: OK [UIDVALIDITY 1645693994] UIDs valid S: OK [UIDNEXT 3] Predicted next UID S: RUBY0040 OK [READ-ONLY] Examine completed (0.001 + 0.020 + 0.019 secs). D, [2022-02-24T11:05:29.798293 #24926] DEBUG -- : Backup 'INBOX' renamed and restored to 'INBOX.1645694009' C: RUBY0041 EXAMINE INBOX.1645694009 S: OK [CLOSED] Previous mailbox closed. S: RUBY0041 NO Mailbox doesn't exist: INBOX.1645694009 (0.015 + 0.020 + 0.033 secs). W, [2022-02-24T11:05:29.852055 #24926] WARN -- : Folder 'INBOX.1645694009' does not exist on server C: RUBY0042 CREATE INBOX.1645694009 S: RUBY0042 OK Create completed (0.021 + 0.020 + 0.039 secs). C: RUBY0043 EXAMINE INBOX.1645694009 S: FLAGS (\Answered \Flagged \Deleted \Seen \Draft) S: * OK [PERMANENTFLAGS ()] Read-only mailbox.

i will delete the email and see if it works

damnms commented 2 years ago

now it works :)

joeyates commented 2 years ago

Hi @damnms

What you're seeing here is the intended behaviour (see below), unfortunately, as per (#115) things will to continue to fail in your case.

The renaming happens because there is a mismatch between the servers identifier for the folder (the "uid_validity") and the value that imap-backup recorded when the backup was run. This behaviour is necessary in order to avoid overwriting stuff when folders get renamed.

As soon as #114 is resolved, imap-backup will do the full restore, but some emails will appear in folders with "$numbers" in their filenames.

bentolor commented 2 weeks ago

Hi @joeyates,

not sure if I'm stumbling over the same issue, especially as the referred tickets are closed. But I just spotted that I got a ton of these files in my backup directory. I rename subfolders quite regularly (but not INBOX?):

$ ls -lah
ls -lah INBOX-*                                                                                                                    Mo 17 Jun 2024 12:42:33 CEST
-rw-rw---- 1 ben ben   53 Apr 29 09:20 INBOX-1705139924-10.imap
-rw-rw---- 1 ben ben    0 Apr 29 09:20 INBOX-1705139924-10.mbox
… many
-rw-rw---- 1 ben ben 2,7M Mai 13 09:42 INBOX-1705511631-11.imap
-rw-rw---- 1 ben ben 6,2G Mai 13 09:42 INBOX-1705511631-11.mbox
-rw-rw---- 1 ben ben 2,7M Mai 20 09:31 INBOX-1705511631-12.imap
-rw-rw---- 1 ben ben 6,2G Mai 20 09:31 INBOX-1705511631-12.mbox
… many many more
-rw-rw---- 1 ben ben 2,7M Apr 29 09:32 INBOX-1705511631-9.imap
-rw-rw---- 1 ben ben 6,2G Apr 29 09:32 INBOX-1705511631-9.mbox
-rw-rw---- 1 ben ben 2,7M Jan 22 09:51 INBOX-1705511631.imap
-rw-rw---- 1 ben ben 6,2G Jan 22 09:51 INBOX-1705511631.mbox
$ du -hs .                                                                                                                           Mo 17 Jun 2024 12:42:40 CEST
100G    .

I understand these are backup/snapshots when a previously known folder see a new ID from server side. I'm just puzzled about the INBOX, as I suspect this folder would be quite stable.

  1. What do I miss?
  2. Can those files be safely deleted if the latest backup is complete & sufficient?