dovecot - May 2006 - Missing mails after folder renaming

Dear List,
I seem to have created myself a problem to which I can't find an answer.
I am using Dovecot (0.99.13-4.FC2 on Fedora Core 2) with Mozilla 
Thunderbird on Windows XP and Linux as IMAP client software.
I renamed a folder to a name that included spaces (it fitted the pupose 
better), then later realised that I would have to change my procmail 
rules to suit. As I wasn't sure what procmail would do with such folder 
names I renamed the folder back to it's original short name (all this 
changing was done in Thunderbird).

The result is that all subfolders under the renamed folder exist in both 
forms:
eg "Computer.SubjectA" and "Computer Projects.SubjectA", but
the second
versions are not seen by Thunderbird although they contain all my old 
mails (new mails are correctly delivered to the short name folders). I 
have tried to move the mails in these folders back to the short name 
folders but the indexing system (I assume) does not 'see' these maildir 
files. How can I fool the system into seeing all the old mails?

Of course, I would like to know why the second renaming didn't work but 
don't have enough information to know if it's Thunderbird or Dovecot 
that isn't working correctly.

As a second question, my Windows clients run in an NT domain (Samba) 
with roaming user profiles. The pathnames for some users become quite 
long and Windows throws a 'path too long' error when saving/loading the 
user profile from the DC. Is there a way of limiting the depth of folder 
nesting under Dovecot to avoid this problem?

I have tried to search for answers but haven't found any yet. If there 
is already some information, I would be glad of a pointer to it.

I am very pleased with the performance of Dovecot in all respects, 
thanks for the program.

Bob von Knobloch.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bob & Sabine von Knobloch wrote:
> Dear List,
> I seem to have created myself a problem to which I can't find an
answer.
> I am using Dovecot (0.99.13-4.FC2 on Fedora Core 2) with Mozilla
> Thunderbird on Windows XP and Linux as IMAP client software.
> I renamed a folder to a name that included spaces (it fitted the pupose
> better), then later realised that I would have to change my procmail
> rules to suit. As I wasn't sure what procmail would do with such folder
> names I renamed the folder back to it's original short name (all this
> changing was done in Thunderbird).
> 
> The result is that all subfolders under the renamed folder exist in both
> forms:
> eg "Computer.SubjectA" and "Computer
Projects.SubjectA", but the second
> versions are not seen by Thunderbird although they contain all my old
> mails (new mails are correctly delivered to the short name folders). I
> have tried to move the mails in these folders back to the short name
> folders but the indexing system (I assume) does not 'see' these
maildir
> files. How can I fool the system into seeing all the old mails?
> 
> Of course, I would like to know why the second renaming didn't work but
> don't have enough information to know if it's Thunderbird or
Dovecot
> that isn't working correctly.
> 
> As a second question, my Windows clients run in an NT domain (Samba)
> with roaming user profiles. The pathnames for some users become quite
> long and Windows throws a 'path too long' error when saving/loading
the
> user profile from the DC. Is there a way of limiting the depth of folder
> nesting under Dovecot to avoid this problem?
> 
> I have tried to search for answers but haven't found any yet. If there
> is already some information, I would be glad of a pointer to it.
> 
> I am very pleased with the performance of Dovecot in all respects,
> thanks for the program.
> 
> Bob von Knobloch.
> 

Bob,

 if both directories still exist on your server but Thunderbird is only
seeing one of them, the first thing I could suggest is checking your
folder subscriptions (in thunderbird) ... it's very likely that the
folder is being seen by thunderbird but just not displayed because it
thinks it's not subscribed.

having said that, if you're going to have folders with spaces in them
then you'll want to escape the space in your procmail rules. so, as an
example if your folder is named ".Computer Science" then in your
procmail rule you'll want to refer to it as ".Computer\ Science"
(without the quotes. although you could probably just put the whole
directory name in quotes and not have to escape the space directly)

That's all basics of the *nix special character escaping scheme and
should be the same regardless of shell or application.

Sorry, I can't offer any information related to the pathname lenghts and
NT/samba.

hope this helps.

Alan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD4DBQFEaIYeE2gsBSKjZHQRAnnqAJjQMHcp3Towzf7GHuQBpwt8GI2QAJ0YSIuz
a+ACpkRrdE6HFgf3Nk8+xA==XyGB
-----END PGP SIGNATURE-----

Bob & Sabine von Knobloch wrote:
> As a second question, my Windows clients run in an NT domain (Samba)
> with roaming user profiles. The pathnames for some users become quite
> long and Windows throws a 'path too long' error when saving/loading
the
> user profile from the DC. Is there a way of limiting the depth of folder
> nesting under Dovecot to avoid this problem?
I guess that it's a problem of your Mail User Agent - it apparently
creates its cache files which have too long names. What's the name of
the MUA in question?

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20060515/1bb8d125/attachment.bin>