[Dovecot] 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-----
alan premselaar schrieb:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
<Snip>
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
Thanks Alan, I wasn't sure if procmail followed the standard *nix quoting system (other parts of the syntax seem to be a bit special), but now I know, I can make the changes I really want. You are right, of course, Thunderbird had not got entries for these folders as being 'subscribed'. I have regained my mails after experimenting (had done the file moving as 'root' and got wrong permissions - will I never learn?). Still have the windows pathlength problem, though. If anybody has an answer, I'd appreciate it.
Bob
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
participants (4)
-
alan premselaar
-
Bob & Sabine von Knobloch
-
Bob von Knobloch
-
Jan Kundrát