Why is Sieve trying to re-compile global scripts?
I have some global scripts that were running nicely.
Then I opened one in an editor and (probably, but not 100% sure) mindlessly saved the file, even though I hadn't made any changes.
Shortly after, Sieve errors started showing in the log:
Error: 4k5JA74R/1TlIwABG/SpMA: sieve: binary save: failed to create temporary file: open(/usr/local/var/dovecot/sieve/script2.svbin.example.com.4139.) failed: Permission denied... Error: 4k5JA74R/1TlIwABG/SpMA: sieve: The LDA Sieve plugin does not have permission to save global Sieve script binaries; global Sieve scripts like `/usr/local/var/dovecot/sieve/script2.sieve' need to be pre-compiled using the sievec tool
Well, OK, is it going by the timestamp on the files? Fine. I recompiled it by hand. Yet, I STILL got these errors!
I triple and quadruple checked that the timestamp on the svbin files was more recent. And Sieve was only complaining about one of the two scripts in the directory.
I restarted dovecot. No change.
So I removed read permission on the .sieve files and only left read permission on the .svbin files. THIS WORKED. No more error. I can live with that, but why was it not complaining before, why was it only complaining about one of my scripts and why would it complain at all when the timestamps on the svbin should have indicated on compilation is needed?
On 3/11/2015 2:10 AM, E.B. wrote:
I have some global scripts that were running nicely.
Then I opened one in an editor and (probably, but not 100% sure) mindlessly saved the file, even though I hadn't made any changes.
Shortly after, Sieve errors started showing in the log:
Error: 4k5JA74R/1TlIwABG/SpMA: sieve: binary save: failed to create temporary file: open(/usr/local/var/dovecot/sieve/script2.svbin.example.com.4139.) failed: Permission denied... Error: 4k5JA74R/1TlIwABG/SpMA: sieve: The LDA Sieve plugin does not have permission to save global Sieve script binaries; global Sieve scripts like `/usr/local/var/dovecot/sieve/script2.sieve' need to be pre-compiled using the sievec tool
Well, OK, is it going by the timestamp on the files? Fine. I recompiled it by hand. Yet, I STILL got these errors!
I triple and quadruple checked that the timestamp on the svbin files was more recent. And Sieve was only complaining about one of the two scripts in the directory.
I restarted dovecot. No change.
So I removed read permission on the .sieve files and only left read permission on the .svbin files. THIS WORKED. No more error. I can live with that, but why was it not complaining before, why was it only complaining about one of my scripts and why would it complain at all when the timestamps on the svbin should have indicated on compilation is needed?
I've heard about this problem before. Do you have the opportunity to test this with the 0.4.7.rc1 release? That adds a few extra debug lines (shown when mail_debug=yes) that would indicate why Sieve is thinking the global script is not up-to-date.
Regards,
Stephan.
I have some global scripts that were running nicely.
Then I opened one in an editor and (probably, but not 100% sure) mindlessly saved the file, even though I hadn't made any changes.
Shortly after, Sieve errors started showing in the log:
Error: 4k5JA74R/1TlIwABG/SpMA: sieve: binary save: failed to create temporary file: open(/usr/local/var/dovecot/sieve/script2.svbin.example.com.4139.) failed: Permission denied... Error: 4k5JA74R/1TlIwABG/SpMA: sieve: The LDA Sieve plugin does not have permission to save global Sieve script binaries; global Sieve scripts like `/usr/local/var/dovecot/sieve/script2.sieve' need to be pre-compiled using the sievec tool
Well, OK, is it going by the timestamp on the files? Fine. I recompiled it by hand. Yet, I STILL got these errors!
I triple and quadruple checked that the timestamp on the svbin files was more recent. And Sieve was only complaining about one of the two scripts in the directory.
I restarted dovecot. No change.
So I removed read permission on the .sieve files and only left read permission on the .svbin files. THIS WORKED. No more error. I can live with that, but why was it not complaining before, why was it only complaining about one of my scripts and why would it complain at all when the timestamps on the svbin should have indicated on compilation is needed?
I've heard about this problem before. Do you have the opportunity to test this with the 0.4.7.rc1 release? That adds a few extra debug lines (shown when mail_debug=yes) that would indicate why Sieve is thinking the global script is not up-to-date.
Yes, I do as a matter of fact. I was just going to put in the RC in order to answer your email on the thread about the RC. Don't have the full answers yet, but when I installed the RC and restarted, I now get an error where Sieve doesn't like that I won't give it read permission on the .sieve file, so now I'm back to square one with this particular issue.
OTOH, regarding my earlier post about the RC ignoring seive files, at least it is seeing global scripts (or trying to). Not sure about personal scripts yet.
Error: TiQJHH2X/1S5UuAAM/SpMA: sieve: file script: Failed to open sieve script: open(/usr/local/var/dovecot/sieve/script1.sieve) failed: Permission denied...
I will do some more testing and report what I find.
I have some global scripts that were running nicely.
Then I opened one in an editor and (probably, but not 100% sure) mindlessly saved the file, even though I hadn't made any changes.
Shortly after, Sieve errors started showing in the log:
Error: 4k5JA74R/1TlIwABG/SpMA: sieve: binary save: failed to create temporary file: open(/usr/local/var/dovecot/sieve/script2.svbin.example.com.4139.) failed: Permission denied... Error: 4k5JA74R/1TlIwABG/SpMA: sieve: The LDA Sieve plugin does not have permission to save global Sieve script binaries; global Sieve scripts like `/usr/local/var/dovecot/sieve/script2.sieve' need to be pre-compiled using the sievec tool
Well, OK, is it going by the timestamp on the files? Fine. I recompiled it by hand. Yet, I STILL got these errors!
I triple and quadruple checked that the timestamp on the svbin files was more recent. And Sieve was only complaining about one of the two scripts in the directory.
I restarted dovecot. No change.
So I removed read permission on the .sieve files and only left read permission on the .svbin files. THIS WORKED. No more error. I can live with that, but why was it not complaining before, why was it only complaining about one of my scripts and why would it complain at all when the timestamps on the svbin should have indicated on compilation is needed?
I've heard about this problem before. Do you have the opportunity to test this with the 0.4.7.rc1 release? That adds a few extra debug lines (shown when mail_debug=yes) that would indicate why Sieve is thinking the global script is not up-to-date.
Yes, I do as a matter of fact. I was just going to put in the RC in order to answer your email on the thread about the RC. Don't have the full answers yet, but when I installed the RC and restarted, I now get an error where Sieve doesn't like that I won't give it read permission on the .sieve file, so now I'm back to square one with this particular issue.
OTOH, regarding my earlier post about the RC ignoring seive files, at least it is seeing global scripts (or trying to). Not sure about personal scripts yet.
Error: TiQJHH2X/1S5UuAAM/SpMA: sieve: file script: Failed to open sieve script: open(/usr/local/var/dovecot/sieve/script1.sieve) failed: Permission denied...
I will do some more testing and report what I find.
I gave read permission to the .sieve files and the same original error happens as with .0.4.6. Now it's complaining about both scripts in my global directory. That it was working without these errors for a while and then complained only about one of the scripts, now both scripts seems to say something but I'm not sure what. Maybe I'll try to recreate the files for fun.
I'll test personal scripts again too...
I have some global scripts that were running nicely.
Then I opened one in an editor and (probably, but not 100% sure) mindlessly saved the file, even though I hadn't made any changes.
Shortly after, Sieve errors started showing in the log:
Error: 4k5JA74R/1TlIwABG/SpMA: sieve: binary save: failed to create temporary file: open(/usr/local/var/dovecot/sieve/script2.svbin.example.com.4139.) failed: Permission denied... Error: 4k5JA74R/1TlIwABG/SpMA: sieve: The LDA Sieve plugin does not have permission to save global Sieve script binaries; global Sieve scripts like `/usr/local/var/dovecot/sieve/script2.sieve' need to be pre-compiled using the sievec tool
Well, OK, is it going by the timestamp on the files? Fine. I recompiled it by hand. Yet, I STILL got these errors!
I triple and quadruple checked that the timestamp on the svbin files was more recent. And Sieve was only complaining about one of the two scripts in the directory.
I restarted dovecot. No change.
So I removed read permission on the .sieve files and only left read permission on the .svbin files. THIS WORKED. No more error. I can live with that, but why was it not complaining before, why was it only complaining about one of my scripts and why would it complain at all when the timestamps on the svbin should have indicated on compilation is needed?
I've heard about this problem before. Do you have the opportunity to test this with the 0.4.7.rc1 release? That adds a few extra debug lines (shown when mail_debug=yes) that would indicate why Sieve is thinking the global script is not up-to-date.
Yes, I do as a matter of fact. I was just going to put in the RC in order to answer your email on the thread about the RC. Don't have the full answers yet, but when I installed the RC and restarted, I now get an error where Sieve doesn't like that I won't give it read permission on the .sieve file, so now I'm back to square one with this particular issue.
OTOH, regarding my earlier post about the RC ignoring seive files, at least it is seeing global scripts (or trying to). Not sure about personal scripts yet.
Error: TiQJHH2X/1S5UuAAM/SpMA: sieve: file script: Failed to open sieve script: open(/usr/local/var/dovecot/sieve/script1.sieve) failed: Permission denied...
I will do some more testing and report what I find.
I gave read permission to the .sieve files and the same original error happens as with .0.4.6. Now it's complaining about both scripts in my global directory. That it was working without these errors for a while and then complained only about one of the scripts, now both scripts seems to say something but I'm not sure what. Maybe I'll try to recreate the files for fun.
The relevant mail_debug lines seem to be these:
dovecot: lmtp(testuser@example.com): Debug: Be3h7iRf/1TnUw2PM/SpMA: sieve: Opening script 1 of 2 from /usr/local/var/dovecot/sieve/script1.sieve' dovecot: lmtp(testuser@example.com): Debug: Be3h7iRf/1TnUw2PM/SpMA: sieve: Loading script /usr/local/var/dovecot/sieve/script1.sieve dovecot: lmtp(testuser@example.com): Debug: Be3h7iRf/1TnUw2PM/SpMA: sieve: binary open: binary /usr/local/var/dovecot/sieve/script1.svbin stored with different binary version 1.2 (!= 1.3; automatically fixed when re-compiled) dovecot: lmtp(testuser@example.com): Debug: Be3h7iRf/1TnUw2PM/SpMA: sieve: Script script1' from /usr/local/var/dovecot/sieve/script1.sieve successfully compiled
Is this possibly due to a mixing of 0.4.6 and 0.4.7 sievec command? Well, I'm not sure that would be it because when I started getting ther error, I recompiled the sieve scrips and restarted dovecot which presumably would have made software versions match up.
On the other hand, I don't know exactly what's happening: I downgraded to 0.4.6 again, intentionally triggered the error by updating the timestamp on the .sieve file, recompiled the script and now the error went away.
I have some global scripts that were running nicely.
Then I opened one in an editor and (probably, but not 100% sure) mindlessly saved the file, even though I hadn't made any changes.
Shortly after, Sieve errors started showing in the log:
Error: 4k5JA74R/1TlIwABG/SpMA: sieve: binary save: failed to create temporary file: open(/usr/local/var/dovecot/sieve/script2.svbin.example.com.4139.) failed: Permission denied... Error: 4k5JA74R/1TlIwABG/SpMA: sieve: The LDA Sieve plugin does not have permission to save global Sieve script binaries; global Sieve scripts like `/usr/local/var/dovecot/sieve/script2.sieve' need to be pre-compiled using the sievec tool
Well, OK, is it going by the timestamp on the files? Fine. I recompiled it by hand. Yet, I STILL got these errors!
I triple and quadruple checked that the timestamp on the svbin files was more recent. And Sieve was only complaining about one of the two scripts in the directory.
I restarted dovecot. No change.
So I removed read permission on the .sieve files and only left read permission on the .svbin files. THIS WORKED. No more error. I can live with that, but why was it not complaining before, why was it only complaining about one of my scripts and why would it complain at all when the timestamps on the svbin should have indicated on compilation is needed?
I've heard about this problem before. Do you have the opportunity to test this with the 0.4.7.rc1 release? That adds a few extra debug lines (shown when mail_debug=yes) that would indicate why Sieve is thinking the global script is not up-to-date.
Yes, I do as a matter of fact. I was just going to put in the RC in order to answer your email on the thread about the RC. Don't have the full answers yet, but when I installed the RC and restarted, I now get an error where Sieve doesn't like that I won't give it read permission on the .sieve file, so now I'm back to square one with this particular issue.
OTOH, regarding my earlier post about the RC ignoring seive files, at least it is seeing global scripts (or trying to). Not sure about personal scripts yet.
Error: TiQJHH2X/1S5UuAAM/SpMA: sieve: file script: Failed to open sieve script: open(/usr/local/var/dovecot/sieve/script1.sieve) failed: Permission denied...
I will do some more testing and report what I find.
I gave read permission to the .sieve files and the same original error happens as with .0.4.6. Now it's complaining about both scripts in my global directory. That it was working without these errors for a while and then complained only about one of the scripts, now both scripts seems to say something but I'm not sure what. Maybe I'll try to recreate the files for fun.
The relevant mail_debug lines seem to be these:
dovecot: lmtp(testuser <at> example.com): Debug: Be3h7iRf/1TnUw2PM/SpMA: sieve: Opening script 1 of 2 from
/usr/local/var/dovecot/sieve/script1.sieve' dovecot: lmtp(testuser <at> example.com): Debug: Be3h7iRf/1TnUw2PM/SpMA: sieve: Loading script /usr/local/var/dovecot/sieve/script1.sieve dovecot: lmtp(testuser <at> example.com): Debug: Be3h7iRf/1TnUw2PM/SpMA: sieve: binary open: binary /usr/local/var/dovecot/sieve/script1.svbin stored with different binary version 1.2 (!= 1.3; automatically fixed when re-compiled) dovecot: lmtp(testuser <at> example.com): Debug: Be3h7iRf/1TnUw2PM/SpMA: sieve: Scriptscript1' from /usr/local/var/dovecot/sieve/script1.sieve successfully compiledIs this possibly due to a mixing of 0.4.6 and 0.4.7 sievec command? Well, I'm not sure that would be it because when I started getting ther error, I recompiled the sieve scrips and restarted dovecot which presumably would have made software versions match up.
On the other hand, I don't know exactly what's happening: I downgraded to 0.4.6 again, intentionally triggered the error by updating the timestamp on the .sieve file, recompiled the script and now the error went away.
After editing one of the global scripts (and compiling it), I am able to get the error back again (and not able to get it to go away). The previous log info I found may have been unrelated and more to do with haivng switched to 0.4.7 without recompiling the scripts.
I'm back with 0.4.6 and the only thing I see in the log now is this:
Debug: lRgL3tO1/1RvOyA6M/SpMA: sieve: Script binary /usr/local/var/dovecot/sieve/script2.svbin is not up-to-date Debug: lRgL3tO1/1RvOyA6M/SpMA: sieve: Script `script2' from /usr/local/var/dovecot/sieve/script2.sieve successfully compiled Error: lRgL3tO1/1RvOyA6M/SpMA: sieve: binary save: failed to create temporary file: open(...
All I can think is that when I initially triggered the error, I noticed that I exited my editor and compiled the script within the *same minute* thus creating timestamps that were equal when compared without seconds. But now, even after recompiling to get a much later timestamp on the binary, I can't get the error to go away.
I upgraded to 0.4.7, and re-compiled one of my two scripts in the same way (during the same minute), and indeed, the first script (that I DID NOT recompile) gets the previous error I saw with the mismatched binary version notice -- that seems irrelevant then, only reltaed to the upgrade.
The script that I did recompile (during the same minute as I saved it) after upgrading causes the same error, so the bug seems consistent across versions. However, there is one additional debug line in version 0.4.7:
sieve: binary up-to-date: script metadata indicates that binary /usr/local/var/dovecot/sieve/script2.svbin is not up-to-date
Doesn't say which metadata.
Downgraded back to 0.4.6, deleted the svbin files, compiled again, and now the error persists. Tried deleting the .sieve source files, re-created them, waited until the next minute, compiled them. Error still in logs. Not sure how I got it to go away last time. Something being cached somewhere?
Not sure how I got it to go away last time.
Might have gotten it to go away by deleting the scripts, causing an email delivery, THEN creating the scripts again.
Although I think my ideas are all flawed:
I can delete the scripts and recreate and recompile all in the same minute and I don't get errors.
I can cause the error to happen again by editing and recompiling one of the files, *whether or not in the same minute* and I do get the error.
This time around, deleting the files and recreating/recompiling them even without an email delivery in between seems to fix the error.
Might be unpredictable caching. Might be the error didn't go away last time I recreated due to different methods of creating the files. Who knows, I think I should give up and stop spamming the list with uneducated guesswork.
On 03/11/2015 07:17 AM, E.B. wrote:
Might be unpredictable caching. Might be the error didn't go away last time I recreated due to different methods of creating the files. Who knows, I think I should give up and stop spamming the list with uneducated guesswork.
No - no spam at least for me.
Please see the thread with subject "Sieve permissions issue following update" I tested sucessfully a developper issue last month on the hint of Stephan. Yesterday I started to test the currenr RCs.
First I was disappointed, because the error seems to persist. So I double checked everything, recreated / recompiled everything an the error went away. So I thought it was mistake on my side. I gave Spephan postive feedback. And I'm waiting for the final release for my production server.
But when I read your mails, I'm not feeling happy. I think it's a kink of luck/voodoo/whatever.
What you must do, I think, is to compile the sieve script with the exact version running afterwards. And I think you should the remove the compiled .svbin files before recreating them again. Don't overwrite them with the compiler.
I think I'll also dig into this any further today.
Olaf
-- Karlsruher Institut für Technologie (KIT) ATIS - Abt. Technische Infrastruktur, Fakultät für Informatik
Dipl.-Geophys. Olaf Hopp
- Leitung IT-Dienste -
Am Fasanengarten 5, Gebäude 50.34, Raum 009 76131 Karlsruhe Telefon: +49 721 608-43973 Fax: +49 721 608-46699 E-Mail: Olaf.Hopp@kit.edu atis.informatik.kit.edu
www.kit.edu
KIT - Universität des Landes Baden-Württemberg und nationales Forschungszentrum in der Helmholtz-Gemeinschaft
Das KIT ist seit 2010 als familiengerechte Hochschule zertifiziert.
On 3/11/2015 11:10 AM, Olaf Hopp wrote:
Please see the thread with subject "Sieve permissions issue following update" I tested sucessfully a developper issue last month on the hint of Stephan. Yesterday I started to test the currenr RCs.
First I was disappointed, because the error seems to persist. So I double checked everything, recreated / recompiled everything an the error went away. So I thought it was mistake on my side. I gave Spephan postive feedback. And I'm waiting for the final release for my production server.
But when I read your mails, I'm not feeling happy. I think it's a kink of luck/voodoo/whatever.
What you must do, I think, is to compile the sieve script with the exact version running afterwards. And I think you should the remove the compiled .svbin files before recreating them again. Don't overwrite them with the compiler.
I think I'll also dig into this any further today.
Please do. I cannot reproduce this so far.
Since E.B. still got an obscure debug message about metadata not being up to date, I added debug lines to the remaining places where this could emerge (currently only available from hg).
Regards,
Stephan.
Since E.B. still got an obscure debug message about metadata not being up to date, I added debug lines to the remaining places where this could emerge (currently only available from hg).
Using hg from just now - first line looks like what you want:
dovecot: lmtp(testuser@example.com): Debug: U5ZtLH8IAVXydgNAM/SpMA: sieve: file script: Binary reports different script location (script2.sieve' rather than /usr/local/var/dovecot/sieve/script2.sieve')
dovecot: lmtp(testuser@example.com): Debug: U5ZtLH8IAVXydgNAM/SpMA: sieve: binary up-to-date: script metadata indicates that binary /usr/local/var/dovecot/sieve/script2.svbin is not up-to-date
dovecot: lmtp(testuser@example.com): Debug: U5ZtLH8IAVXydgNAM/SpMA: sieve: Script binary /usr/local/var/dovecot/sieve/script2.svbin is not up-to-date
Using hg from just now - first line looks like what you want:
dovecot: lmtp(testuser@example.com): Debug: U5ZtLH8IAVXydgNAM/SpMA: sieve: file script: Binary reports different script location (
script2.sieve' rather than/usr/local/var/dovecot/sieve/script2.sieve') dovecot: lmtp(testuser@example.com): Debug: U5ZtLH8IAVXydgNAM/SpMA: sieve: binary up-to-date: script metadata indicates that binary /usr/local/var/dovecot/sieve/script2.svbin is not up-to-date dovecot: lmtp(testuser@example.com): Debug: U5ZtLH8IAVXydgNAM/SpMA: sieve: Script binary /usr/local/var/dovecot/sieve/script2.svbin is not up-to-date
Also, it does appear that blowing away *everything* in my global script location (is removing the svbin file the key?) and re-creating it all seems to fix the problem.
On 03/12/2015 12:02 AM, Stephan Bosch wrote:
On 3/11/2015 11:10 AM, Olaf Hopp wrote:
Please see the thread with subject "Sieve permissions issue following update" I tested sucessfully a developper issue last month on the hint of Stephan. Yesterday I started to test the currenr RCs.
First I was disappointed, because the error seems to persist. So I double checked everything, recreated / recompiled everything an the error went away. So I thought it was mistake on my side. I gave Spephan postive feedback. And I'm waiting for the final release for my production server.
But when I read your mails, I'm not feeling happy. I think it's a kink of luck/voodoo/whatever.
What you must do, I think, is to compile the sieve script with the exact version running afterwards. And I think you should the remove the compiled .svbin files before recreating them again. Don't overwrite them with the compiler.
I think I'll also dig into this any further today.
Please do. I cannot reproduce this so far.
Since E.B. still got an obscure debug message about metadata not being up to date, I added debug lines to the remaining places where this could emerge (currently only available from hg).
Regards,
Stephan.
Hi, I'm still trying but currently I can not reproduce the bug. But I will keep on hammering on it.
Olaf
-- Karlsruher Institut für Technologie (KIT) ATIS - Abt. Technische Infrastruktur, Fakultät für Informatik
Dipl.-Geophys. Olaf Hopp
- Leitung IT-Dienste -
Am Fasanengarten 5, Gebäude 50.34, Raum 009 76131 Karlsruhe Telefon: +49 721 608-43973 Fax: +49 721 608-46699 E-Mail: Olaf.Hopp@kit.edu atis.informatik.kit.edu
www.kit.edu
KIT - Universität des Landes Baden-Württemberg und nationales Forschungszentrum in der Helmholtz-Gemeinschaft
Das KIT ist seit 2010 als familiengerechte Hochschule zertifiziert.
On 3/12/2015 11:56 AM, Olaf Hopp wrote:
On 03/12/2015 12:02 AM, Stephan Bosch wrote:
On 3/11/2015 11:10 AM, Olaf Hopp wrote:
Please see the thread with subject "Sieve permissions issue following update" I tested sucessfully a developper issue last month on the hint of Stephan. Yesterday I started to test the currenr RCs.
First I was disappointed, because the error seems to persist. So I double checked everything, recreated / recompiled everything an the error went away. So I thought it was mistake on my side. I gave Spephan postive feedback. And I'm waiting for the final release for my production server.
But when I read your mails, I'm not feeling happy. I think it's a kink of luck/voodoo/whatever.
What you must do, I think, is to compile the sieve script with the exact version running afterwards. And I think you should the remove the compiled .svbin files before recreating them again. Don't overwrite them with the compiler.
I think I'll also dig into this any further today.
Please do. I cannot reproduce this so far.
Since E.B. still got an obscure debug message about metadata not being up to date, I added debug lines to the remaining places where this could emerge (currently only available from hg).
Regards,
Stephan.
Hi, I'm still trying but currently I can not reproduce the bug. But I will keep on hammering on it.
Looks like I found the bug. Will need some time to fix this properly.
Regards,
Stephan.
On 3/12/2015 11:53 PM, Stephan Bosch wrote:
On 3/12/2015 11:56 AM, Olaf Hopp wrote:
On 03/12/2015 12:02 AM, Stephan Bosch wrote:
Please do. I cannot reproduce this so far.
Since E.B. still got an obscure debug message about metadata not being up to date, I added debug lines to the remaining places where this could emerge (currently only available from hg).
Regards,
Stephan.
Hi, I'm still trying but currently I can not reproduce the bug. But I will keep on hammering on it. Looks like I found the bug. Will need some time to fix this properly.
I released rc2. Please check whether this resolves the issues.
Regards,
Stephan.
On 03/15/2015 12:37 AM, Stephan Bosch wrote:
On 3/12/2015 11:53 PM, Stephan Bosch wrote:
On 3/12/2015 11:56 AM, Olaf Hopp wrote:
On 03/12/2015 12:02 AM, Stephan Bosch wrote:
Please do. I cannot reproduce this so far.
Since E.B. still got an obscure debug message about metadata not being up to date, I added debug lines to the remaining places where this could emerge (currently only available from hg).
Regards,
Stephan.
Hi, I'm still trying but currently I can not reproduce the bug. But I will keep on hammering on it. Looks like I found the bug. Will need some time to fix this properly.
I released rc2. Please check whether this resolves the issues.
With RC2 everything looks good !
And finally I could reproduce the bug: with 0.4.5 and 0.4.7 RC1 you can trigger it when you compile the master sieve script with a *relative* path:
cd /etc/dovecot /usr/bin/sievec -D ./sieve-master
will trigger it. Whereas /usr/bin/sievec -D /etc/dovecot/sieve-master even with 0.4.5 will run fine.
With 0.4.7 RC2 it makes no difference, wether you use an absolute or a relative path to the sieve-master script.
Olaf
-- Karlsruher Institut für Technologie (KIT) ATIS - Abt. Technische Infrastruktur, Fakultät für Informatik
Dipl.-Geophys. Olaf Hopp
- Leitung IT-Dienste -
Am Fasanengarten 5, Gebäude 50.34, Raum 009 76131 Karlsruhe Telefon: +49 721 608-43973 Fax: +49 721 608-46699 E-Mail: Olaf.Hopp@kit.edu www.atis.informatik.kit.edu
www.kit.edu
KIT - Universität des Landes Baden-Württemberg und nationales Forschungszentrum in der Helmholtz-Gemeinschaft
Das KIT ist seit 2010 als familiengerechte Hochschule zertifiziert.
participants (3)
-
E.B.
-
Olaf Hopp
-
Stephan Bosch