[1.9.4] Mailhandler is stuk

[Kees]

Als ik een post probeer te plaatsen met de mailhandler:

Fatal error: Call to undefined function: get_topic_fields() in /....../global/non-www/actionclasses/mailhandler.classes.inc.php on line 1430

[Spider.007]

Snelle oplossing; even de mailhandler.classes renamen; maar het pad aan het begin ziet er ook niet helemaal jofel uit?

[Kees]

Spider.007 schreef op maandag 31 juli 2006 @ 12:57:
Snelle oplossing; even de mailhandler.classes renamen; maar het pad aan het begin ziet er ook niet helemaal jofel uit?

Dat komt omdat ik te lang op '.' heb lopen rammen begin is niet interesant en is een redelijk lang path dat niet van belang is om te weten

Maar renamen: waarheen?

[ Voor 3% gewijzigd door Kees op 31-07-2006 13:01 ]

[chem]

als hij maar niet gevonden kan worden
desnoods mv je hem naar /tmp

[Kees]

ok, gemoved.
Hij geeft geen error meer \o/

(maar ook geen post in het betreffende forum met de betreffende gebruiker)

edit: nieuwe errors zijn verschenen:

An error occured while processing your request.
Met dit bestand overschrijf je je quote met 266897.62 mb. Verwijder aub. eerst wat bestanden voor je een nieuw bestand upload.
(topic::new_message::max_upload_reached)

[ Voor 52% gewijzigd door Kees op 31-07-2006 13:12 ]

[Spider.007]

Je du-binary setting klopt; en je draait niet in safe-mode? Welke versie van du draai je? Heb je uberhaupt quota's geconfigureerd in de admin

[Kees]

quota's staan goed, ik heb de attachment dir even volledig leeggepleurd nu voor die user, er stond 16mb aan data in.


ik zal de du even gaan controleren

[ Voor 24% gewijzigd door Kees op 31-07-2006 13:21 ]

[Spider.007]

Dit probleem kan ook heel goed gerelateerd zijn aan het feit dat 1.9.4 itt 1.9.3 de attachments niet meer in /attachments/ neerzet; maar in de documentlibrary probeert te plaatsen. Ik gok dat die map niet is aangemaakt; danwel de juiste permissies heeft? board/non-www/documentlibraries/

[Kees]

Spider.007 schreef op maandag 31 juli 2006 @ 13:25:
Dit probleem kan ook heel goed gerelateerd zijn aan het feit dat 1.9.4 itt 1.9.3 de attachments niet meer in /attachments/ neerzet; maar in de documentlibrary probeert te plaatsen. Ik gok dat die map niet is aangemaakt; danwel de juiste permissies heeft? board/non-www/documentlibraries/

Deze is er al wel, en heeft nu ook de juiste permissies

[Spider.007]

Is het probleem daarme opgelost? Zie je dat er een [userid]/documentid worden aangemaakt?

[Kees]

juiste permissies (zelfde als attachments / usericon dir nu)
geen php errors in /tmpo/maillog
react error blijft komen:

An error occured while processing your request.
Met dit bestand overschrijf je je quote met 266897.62 mb. Verwijder aub. eerst wat bestanden voor je een nieuw bestand upload.
(topic::new_message::max_upload_reached)

Quota voor deze user staat op 100MB, attachments mogen geupload worden, du locatie staat goed.

- ik denk dat ik nog wat moet syncen
-- done by crisp, testmail onderweg..

[ Voor 7% gewijzigd door Kees op 31-07-2006 13:32 ]

[Kees]

Nope, blijf de error houden, inclusief het wel heel erg vreemde getal van '266897.62 mb'

[Spider.007]

We gaan kijken of we het attachen van de originele message als document-library-item kunnen uitschakelen; of gebruiken julie die functionaliteit wel? De hele documentlibrary staat hier namelijk niet aan; dus je zal de attchement toch erg lastig weer kunnen downloaden

[Kees]

Als ik zo de output bekijk blijft het hangen op de vrije ruimte van de quota, deze wordt niet goed berekend. Hoe berekenen jullie het met du? welke switches?

Anyway, ook al staat de quote in de admin op 100mb, hij blijft roepen dat het slechts 10kb is in de output die ik krijg.

Spider.007 schreef op maandag 31 juli 2006 @ 14:01:
We gaan kijken of we het attachen van de originele message als document-library-item kunnen uitschakelen; of gebruiken julie die functionaliteit wel? De hele documentlibrary staat hier namelijk niet aan; dus je zal de attchement toch erg lastig weer kunnen downloaden

Gooi maar uit, gebruiken we toch niet, en zorgde er alleen maar voor dat onze attachments dir meer had dan de readme.txt

[ Voor 47% gewijzigd door Kees op 31-07-2006 14:04 ]

[chem]

we gebruiken du -s; wat je kan doen is een du-bash file maken die 0 teruggeeft (niets in gebruik).
nadeel is dat de usericons dan ook geen diskspace meer innemen... ei'k moeten we het gewoon juist rekenen

[Spider.007]

we gebruiken

du -bs 2>/dev/null

en ik denk dat het probleem niet in du; maar in de quota's zit. Als `du` namelijk 0 zou teruggeven zou je je complete quota vrij moeten hebben; maar dat is weer niet zo

[Joror]

Je kan wel deze attachment uit zetten door dit in je settings file te zetten:

$settings['mailhandler_accounts'][$account]['dontstoreinzip'] = false;

(dat ie op 'false' moet en niet op 'true' is wel een bugje)

[Kees]

Onze huidige settings:

$settings['mailhandler_accounts'] = array(
'default' => array('forumid' => 67, 'userid' => 72152),
'*censuur*@tweakers.net' => array('forumid' => xx, 'userid' => xxx, 'allowhtml' => true, 'prefertext' => false, 'dontstoreinzip' => false)
);

Dit was overigens 'dontstorezip' => true. maar zowel deze waarde naar false zetten, als de dontstoreinzip op false zetten lost het probleem niet op. Hij blijft klagen over de grootte van mijn quota met 266 gigabyte (wat overigens bijna de vrije ruimte is op een andere harde schijf in datzelfde systeem toevallig). du -bs levert ook prima '0 .' op in de juiste dir.
Al met al blijft het vreemd, ruimte zat en ik heb nog geen users horen klagen over het feit dat ze geen icons meer konden uploaden

Nu ook de 'du' voor deze user vervangen door een 'fakedu' die gewoon '0' teruggeeft. Maar hij blijft klagen over het overschrijden van de quota met veel mb's (overigens ook een typo in die error, het is volgens mij 'quota' en niet 'quote')

[ Voor 12% gewijzigd door Kees op 31-07-2006 17:35 ]

[Joror]

Gefixt - maar moet nog even goed getest worden onder jullie omstandigheden als het live gaat. (deed het nl hier eerst wel goed nog)