Hi, I use Patterns in .mbsynrc and there I can have things like "[Gmail]/Spam" with no problems. E.g.,
Channel home-updown Far :home-remote: Near :home-local: Patterns "INBOX" "[Gmail]/Spam" "[Gmail]/Trash" "[Gmail]/Drafts" "2read" Expunge Both Channel home-up Far :home-remote: Near :home-local: Patterns * ![Gmail]* !INBOX !2read Create Far Sync Push Expunge Far (And locally, I flatten paths: Flatten . ) As for trash, try this link: https://mail.google.com/mail/u/0/#search/has%3Anouserlabels+-in%3ASent+-in%3AChat+-in%3ADraft+-in%3AInbox (equivalent to search query has:nouserlabels -in:Sent -in:Chat -in:Draft -in:Inbox i.e., mails without labels other than in Sent, Chat, Draft, Inbox). Whenever I delete something locally without moving it in trash, the email ends up here. I did that for years without ever seeing the above unlabeled lot so now each evening a script launches the above url for me and I delete 100, decade-old mails via the web interface. I haven't come up with a better way, but also it's only two clicks and it's fun to see what I was doing in 2013 ;-). Other than this, I pretend that Google works with actual folders so I let mbsync mimic the label structures as my local maildir folders. I only save each mail into one folder so don't get duplicates. I only use notmuch for indexing to provide search when needed, not for labels. Trying to KISS. Hope this is somewhat helpful, best wishes, Marton On Wed, Nov 26, 2025 at 02:27:59PM +0200, Gesh wrote: > 26.11.2025 12:50:02 Oswald Buddenhagen <[email protected]>: > > > On Thu, Nov 06, 2025 at 02:43:55AM +0200, Gesh wrote: > >>> Error: channel gesh-iobox: near side box [Gmail]/Sent Mail cannot be > opened. > >> Investigating suggests I need to escape the name of the near-side box by > writing > >> it as > >>> Channel gesh-iobox-sent > >>> Far :gesh-remote:"[Gmail]/Sent Mail" > >>> Near :gesh-local:"\\[Gmail\\]/Sent Mail" > >>> > > huh ... where did you get that from? > > Experimenting with various syntaxes, this was the only one that didn't throw > errors - unclear why, though. > > >> A tangential bug I had here is that for some reason, syncing messages meant > that a bunch of them had their delivery times reset *on the server end*, > >> > > i suppose this would happen if the messages are moved between boxes > client-side (and thus re-delivered to gmail's unified inbox). > > It's been a while, I've forgotten if this was also in my standard addresses, > but I made the mistake of trying to use this to mirror emails to a backup > account which was already getting emails by bouncing them. I'm unsure if that > was well-advised. > > >> An alternative concept would be to patch mbsync so it stores/updates IMAP > extension attributes. Eg for Gmail[1], a configuration such as > >>> IMAPAccount ... > >>> StoreAttr X-GM-MSGID X-GM-THRID X-GM-LABELS > >>> UpdateAttr X-GM-LABELS > >> > > i think it's a bit "optimistic" that one could just name random attributes > and expect them to be handled usefully without isync knowing their semantics. > > anyway, there is a long-standing todo item to support imap keywords. > > OK, so how do you approach the situation that > - gmail duplicates emails across folders to simulate multi-labeling > - in particular, it has a catchall folder containing all mail > - I use both a phone and a computer, so any relabelling needs to be propagated > back serverside so the phone picks it up > > I _guess_ I could configure notmuch to ignore the all-mail folder for > day-to-day, then double check from time to time that I'm not losing any mail > there, and otherwise just use folders as folders? > > >> Finally finally, I'm not sure I 100% understand the guidance re trashing/ > expunging and its interaction with Gmail -- > > > >> do I understand correctly that the default behaviour is for the Gmail > >> server > to automatically delete email once it's vanished from all labels, > >> > > dunno. i don't actively use gmail, and haven't looked at the settings for a > few years. > > > >> preventing batch processing, > >> > > no idea what you mean here. > > > >> and that the recommended behavior instead is to set it to move messages to > Trash once their final copy is expunged? > >> > > gmail may have a setting to trash on expunge. using that would be a good > choice, indeed. > > I'm asking for clarification as to the first paragraph of the recommendations > - > not clear on what the default is and what should be changed. > > Thanks! > Gesh > _______________________________________________ > isync-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/isync-devel _______________________________________________ isync-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/isync-devel
