Howdy! On Tuesday, August 8 at 02:25 PM, quoth Rocco Rutte:
Thus, you can extract the original filename with this simple code:char * tail = strrchr(filename, ':'); if (tail) *tail = 0; printf("IMAP UID is %s\n", filename);Tada!No. You can't do this efficiently.What your code does is: 'I have a filename and now tell me which server UID it is'. This works, of course, but it's not what we want.What we want is: 'I have a unique server ID and now give me the local filename'.
Ahh, gotcha. Hmm, well, it depends on what you're keeping in memory then. One could keep something like a trie structure in memory containing the filenames of messages in the cache. The only real issue there is concurrent access---need to be able to prevent people from viewing (and editing) the cache while your other mutt is using it.
If you can fetch the UID and the flags from the IMAP server, I think you should be able to reconstruct the filename ("UID:2,FLAGS"), provided you can prevent people from modifying the filename on their own time. Can this be accomplished by careful manipulation of the read/write permissions of the maildir cur/ directory? I mean, most mail readers don't muck with that, and if we carefully manipulate it to be writable only while we need to open() a new file, then there's only a very small opportunity for corruption if someone's doing something silly (e.g. flagging an offline message).
Then again, "ls UID:2,*" finds the message I want reasonably quickly (translation: a linear search). Doesn't work as well in folders with giant gobs of messages, but then, that's only necessary the first time---after that I can cache (say) the inode number of the file in memory (a map of number-to-number shouldn't need much memory, right?).
Now, on the other hand, there's the mh format.So, the problem with something like an mh folder is storage of flags (I think), because they store flags in an X-Status: header much like an mbox (if memory serves). This should be easily solved by simply setting messages stored there to be read-only, shouldn't they?
If a client mangled the maildir filenames (_not_ just mutt!), we'd have go through all of them one by one, and compare the first n characters and check for the maildir suffix.
This should only be a problem if they're *modifying* the flags of the messages, which they shouldn't be doing as long as mutt puts the messages into the cur/ directory, and as long as they don't do something silly like try to change the flags of the messages in the cache (which I think is essentially shooting themselves in the foot, and they deserve what they get).
Perhaps a script to do so would be a nice thing to add to the docs?That could be done, of course. But Brendan's intention (which I support) is to prevent the majority of user doing this (for now) to prevent bug reports or the like because filenames are mangled.
Well, but what about something like you suggested: symlinks. Like so:
#!/bin/bash
mkdir -p ./OfflineMaildir/cur
mkdir -p ./OfflineMaildir/new
mkdir -p ./OfflineMaildir/tmp
for F in $message_cache/* ; do
bname=`basename "$F"`
ln -s "$F" "./OfflineMaildir/cur/$bname:2,S"
done
chmod -R a-r ./OfflineMaildir
Any flag-based mucking just twiddles the symlink, and the cache is
left alone. (Obviously that would have to be edited before being
released as a general-purpose "cache-viewer.sh" sort of tool.)
Just many things are misleading here. For example, if a maildir message is flagged, replied, etc it has a proper maildir suffix, but from the name in the body cache you can't tell as flags are managed at a different place. So enabling by default _could_ produce many mails by people complaining about 'wrong' or 'missing' flags when viewing it as maildir.
Hrm, good point. On the other hand, so what? The goal is to make it possible to view things semi-conveniently offline, not to perfectly replace actually having a network connection.
~Kyle --The longer I live the more I see that I am never wrong about anything, and that all the pains that I have so humbly taken to verify my notions have only wasted my time.
-- George Bernard Shaw
Attachment:
pgpoYY5QH4wOe.pgp
Description: PGP signature