nametrans confusion ...

Cameron Simpson cs at zip.com.au
Fri Feb 17 22:54:32 GMT 2012 

On 16Feb2012 16:23, Sebastian Spaeth <Sebastian at SSpaeth.de> wrote:
| On Wed, 8 Feb 2012 14:18:05 +1100, Cameron Simpson <cs at zip.com.au> wrote:
| > "OLD/2012/getmail". The remote folder may be "MD/OLD/2012/getmail" or
| > "MD/OLD.2012.getmail" or even "MD.OLD.2012.getmail"
[...]
| your local nametrans essentially prefixes "MD/" to any path.

Yes.

| There is no
| need for separator munging, we do that ourselves.

So, I want a "sep = /" in my local repository config, since I want
subdirs? And no sep in the remote config because it is unused, because
you know it from the remote IMAP service?

| I'd probably use:
| nametrans lambda f: "MD/" + f
| (but your solution looks good too)

That's roughly what I do have, plus the dot and slash munging.
It is only off in a separate file so I can put debugging statements in
it.

| >   def there2here(rf):
| >     f = rf[len(prepath):] if rf.startswith(prepath) else rf
| >     print >>sys.stderr, "there2here(%s) -> %s" % (rf, f)
| >     return f
| 
| so your remote nametrans essentially strips away and mention of MD/, it
| seems.

Yes. I'm hoping to never receive a path without a leading MD/; I should
not, correct?

Now, I'm stripping "MD/". Does that imply that all the remote separators
are slashes by the time you hand the remote folder name to nametrans?
Does that in turn imply you use the local "sep =" setting to do a little
premangling to the remote folder names before showing them to me? What
if the local "sep=" was another character?

| In a current version of OfflineImap, what does "--info" output? It
| should show you a list of foldermappings and what is being filtered
| out. (you can also use the -f option with it).
| 
| Now that I come to think about it, I see what might be an issue. The -f
| option works on the untranslated remote folder name. And that is not
| MD/OLD/2012/getmail but MD.OLD.2012.getmail I guess. Does that work?

Following these suggestions partway I have done two things: I've split
the myfolders() function into two duplicates, so as to tell whether it
is being called for a local or remote folder. And I have used
"MD.OLD.2012.hg" on the command line.

As an aside, I would note that requiring untranslated remote folder names on the
command line makes things tricky for wrapper scripts. I, for example,
don't know the folder names on the far side with precision; I still
don't know if they are MD.OLD.2012.hg or MD/OLD/2012/hg or
MD/OLD.2012.hg, and I also don't know if your own separator knowledge is
applied before of after I look at the remote name. The other half is
that if I have to provide untranslates remote names then the wrapper
script (not written in python at present, and hopefully won't need to be)
somehow needs to know about the nametrans function.

If -f took _local_ folder names the offlineimap could apply the local
nametrans, keeping the magic inside the offlineimap config file.

Returning to the test runs, there's a run below and a second run with
--info, and remarks.

The python functions now read:

  prepath = 'MD/'

  def here2there(f):
    rf = prepath + f.replace('.', '/')      ## .replace('/', '.')
    if my_l_folders(f): print >>sys.stderr, "here2there(%s) -> %s" % (f,
  rf)
    return rf

  def there2here(rf):
    f = (rf[len(prepath):] if rf.startswith(prepath) else rf)
    if my_r_folders(rf): print >>sys.stderr, "there2here(%s) -> %s" % (rf,
  f)
    return f

  def my_l_folders(f):
    useme = 'hg' in f and 'OLD' in f and '2012' in f
    if useme: print >>sys.stderr, "my_l_folders(%s) -> %s" % (f, useme)
    return useme

  def my_r_folders(rf):
    useme = 'hg' in rf and 'OLD' in rf and '2012' in rf
    if useme: print >>sys.stderr, "my_r_folders(%s) -> %s" % (rf, useme)
    return useme

The offlineimaprc says:

  [Account _Users_cameron_tmp_oi::cameron at cskk.local:143]
  localrepository = _Users_cameron_tmp_oi
  remoterepository = cameron at cskk.local:143
  folderfilter = lambda f: myfolders(f)

  [Repository _Users_cameron_tmp_oi]
  type = Maildir
  localfolders = /Users/cameron/tmp/oi
  sep = /
  nametrans = lambda foldername: here2there(foldername)
  folderfilter = lambda f: my_l_folders(f)

  [Repository cameron at cskk.local:143]
  type = IMAP
  nametrans = lambda foldername: there2here(foldername)
  folderfilter = lambda f: my_r_folders(f)

Running:

  offlineimap -c /Users/cameron/tmp/imap-sync.26891.cfg -f MD.OLD.2012.hg

shows:

  OfflineIMAP 6.5.2.1
    Licensed under the GNU GPL v2+ (v2 or any later version)
  folderfilter = ['MD.OLD.2012.hg']
  *** Processing account _Users_cameron_tmp_oi::cameron at cskk.local:143
  Establishing connection to cskk.local:143
  my_r_folders(MD/OLD/2012/hg) -> True
  there2here(MD/OLD/2012/hg) -> OLD/2012/hg
  my_l_folders(OLD/2012/hg) -> True
  here2there(OLD/2012/hg) -> MD/OLD/2012/hg
  my_l_folders(OLD.2012.hg) -> True
  here2there(OLD.2012.hg) -> MD/OLD/2012/hg
  *** Finished account '_Users_cameron_tmp_oi::cameron at cskk.local:143' in
  0:01

And no new messages appear, either. There are new message on the
remote.

The above trace suggests that the folder filters are only being called
from inside the nametrans functions and never from the folder filter. Is
that because I have a -f command line option? The doco suggests so, and
the code suggests that the -f basicly replaces a config file folderfilter
with a filter computed from the -f option.

Running with --info per your suggestion:

  Establishing connection to cskk.local:143
  Server supports ID extension.
  Server welcome string: * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR
  LOGIN-REFERRALS ID ENABLE IDLE STARTTLS AUTH=PLAIN] Dovecot ready.
  Server capabilities: ('IMAP4REV1', 'LITERAL+', 'SASL-IR',
  'LOGIN-REFERRALS', 'ID', 'ENABLE', 'IDLE', 'SORT', 'SORT=DISPLAY',
  'THREAD=REFERENCES', 'THREAD=REFS', 'MULTIAPPEND', 'UNSELECT',
  'CHILDREN', 'NAMESPACE', 'UIDPLUS', 'LIST-EXTENDED', 'I18NLEVEL=1',
  'CONDSTORE', 'QRESYNC', 'ESEARCH', 'ESORT', 'SEARCHRES', 'WITHIN',
  'CONTEXT=SEARCH', 'LIST-STATUS')

  folderfilter= lambda f: f in ['MD.OLD.2012.hg']

  folderincludes= []

  nametrans= lambda foldername: there2here(foldername)

  my_r_folders(MD/OLD/2012/hg) -> True
  there2here(MD/OLD/2012/hg) -> OLD/2012/hg
  Folderlist:
   INBOX (disabled)
   MD/Junk -> Junk (disabled)
   MD/KNOWN -> KNOWN (disabled)
   MD (disabled)
   MD/OLD/2012/-spam -> OLD/2012/-spam (disabled)
   MD/OLD/2012/U -> OLD/2012/U (disabled)
   [...]
   MD/OLD/2012/haproxy -> OLD/2012/haproxy (disabled)
   MD/OLD/2012/hg -> OLD/2012/hg (disabled)
   [...]
   MD/OLD/2012/zsh -> OLD/2012/zsh (disabled)
   MD/OLD/2012/zsi -> OLD/2012/zsi (disabled)
   MD/POSTPONED -> POSTPONED (disabled)
   [...]
   MD/haproxy -> haproxy (disabled)
   MD/hg -> hg (disabled)
   [...]
   MD/zsh -> zsh (disabled)
   MD/zsi -> zsi (disabled)

  Local repository '_Users_cameron_tmp_oi': type 'Maildir'
  folderfilter= lambda f: f in ['MD.OLD.2012.hg']

  folderincludes= []

  nametrans= lambda foldername: here2there(foldername)

  my_l_folders(OLD/2012/hg) -> True
  here2there(OLD/2012/hg) -> MD/OLD/2012/hg
  Folderlist:
   OLD/2012/hg -> MD/OLD/2012/hg (disabled)

I've snipped out a lot of irrelevant folders with "[...]" above but left
some context. Does this provide any insight?

Cheers,
-- 
Cameron Simpson <cs at zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

We are all agreed that your theory is crazy. The question that divides us is
whether it is crazy enough to have a chance of being correct.
- Niels Bohr (to Wolfgang Pauli), 1958

More information about the OfflineIMAP-project mailing list