[horde] Cannot write to cache directory /tmp

[Simon B]

On 4 June 2013 20:36, Michael M Slusarz <slusarz at horde.org> wrote:
> Quoting Simon B <simon.buongiorno at gmail.com>:
>
>> On 3 June 2013 15:20, Michael J Rubinsky <mrubinsk at horde.org> wrote:
>>>
>>>
>>> Quoting Simon B <simon.buongiorno at gmail.com>:
>>>
>>>> On 3 June 2013 09:51, Ole Wolf <ole at naturloven.dk> wrote:
>>>>>
>>>>>
>>>>>  Quoting Simon B <simon.buongiorno at gmail.com>:
>>>>>
>>>>>> The browser says
>>>>>>
>>>>>> Cannot write to cache directory /tmp
>>>>>>
>>>>>> But /tmp is owned by www-data
>>>>>>
>>>>>
>>>>>
>>>>> Last time I had that error (incidentally, it was after a Horde update,
>>>>> too)
>>>>> it was because the disk was full.
>>>>
>>>>
>>>>
>>>> Great spot.  That's the second time a git pull has left me with a full
>>>> disk - 500GB!..  After a reboot, I'm back to 12% or just under 50GB..
>>>
>>>
>>>
>>> http://bugs.horde.org/ticket/12265
>>
>>
>> Yes and no.  I'm sure you're right as you know much more about IMAP
>> than I do, but my concerns are:
>>
>> 1) As you say in the ticket - it's amazing how many people are running
>> around with "broken" imap servers - given the number of different IMAP
>> servers that were mentioned, makes me concerned that it's not the IMAP
>> server - but rather the way it's being spoken to.
>
>
> It's not.  They are broken servers.  As stated in the ticket, it was a
> regression in our code that caused these broken servers to cause issues.
> But there's no issues with the commands we are sending.

I saw in the ticket that this was "fixed in git" but as I have the
latest git, and since my issue happened after that was posted, I'm
inclined to say we aren't talking about the same bug, or it's not
fixed.  I think the former.

>> Google seems to think
>> this is a unclosed file handle.  If that's a Dovecot bug, I find it
>> strange that I'm only discovering it now an b) that Timo hasn't fixed
>> it yet..
>
>
> As good as Timo is, he's not superhuman.  Bugs exist in everyone's code
> (including ours).  I have found one in his 2.2.2 CATENATE handling code that
> he hasn't yet fixed.  So this last bit is just wrong and not useful in
> analyzing a bug report (i.e. "A bug must exist in B because A is such good
> software").

That was not my contention at all.  If you will my contention was more
along the lines of...

It's likely that the bug exists in B because there are orders of
magnitude more people using A who would have reported it to a very
active and responsive developer.

I'm well aware Dovecot might have bugs neither you, me nor Timo know
about it.  But 1.2 is acknowledged to be very very stable code -
whilst it's not possible to state conclusively, I feel like if it was
"broken" I wouldn't be the first person noticing it.  If you like that
last clause is a better surmise of my argument than A bug myst exist
in B because is A such good software.

Simon