Closed damnms closed 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
now it works :)
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.
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.
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?