#5 Dynamically rewriting folder paths

[Marc]

I am thinking about introducing two new per-store configuration options which allow rewriting the folder path before interacting with the store. I basically would like to make the en- and decoding part of this patch a configurable feature: http://chrisstreeter.com/static/images/2009/04/recursive_imap_ubuntu.patch

The options would probably be something like:

• RewritePathIn regular-expression replacement-pattern
• RewritePathOut regular-expression replacement-pattern

Or it could be channel-specific and use the existing direction terms:

• PullRewritePath regular-expression replacement-pattern
• PushRewritePath regular-expression replacement-pattern

What does everyone else think?

[Oswald Buddenhagen]

i've been pondering that at lengths.
what i did not come up with was a good use case ...

[Marc]

The use case for me is syncing GMail labels to a Maildir store. Problems arise once you have nested labels with / in them since that character has a special meaning in filesystems. The patch linked above was used to escape them.

Another valid use case would be different Maildir folder prefixes or folder depths. E.g. dot in front of folder or not; or everything in INBOX or not. Having regular expressions would add a great amount of flexibility.

[Oswald Buddenhagen]

ok, i buy that.
of course, with great flexibility comes with a great risk of botching it and thus causing serious data loss. you'll need to add some test mode (a subfunction of the list command, i think).
you need to do it per-store, because isync needs a normalized path style for the list command and the Pattern matching. note that in/out are unclear, because the object is unclear. maybe imap-like fetch/store.

[Oswald Buddenhagen]

fwiw, i recently pushed a change to enable multi-character path separators (which was misguided after all, but never mind) which should make implementing such universal path rewriting on top sort of simple.

thinking of it again, you don't need a special mode to verify the validy of the transformation - it should be simply part of the normal operation (after each transformation the reverse is applied - if it yields something else than the original string, immediately abort).

[Yuxuan Shui]

This could also be used to provide a compatible behavior with Evolution. As Evolution expects a subfolder's path like 'folder/subfolder', but mbsync creates it as 'folder/.subfolder'.

[Mark Brown]

I'd just like to second Yuxuan Shui's comment: it's not just Evolution, when using mutt with Maildirs locally it's really noticeable that all the folders end up as hidden directories which is not expected behavior. This also prevents me sharing my mutt configuration with others that use direct connection to the server (I have a small fragment which configures the server connection).

An option to elide the leading '.'s from the folder names would also address the specific issue we both seem to be running into.