Bugsink: https://bugsink.cytrus.de/issues/issue/2d703bd3-b728-4dd9-ae74-92b49d7a513b/event/last/

Typ: NEW issue

Projekt: www-verl-de

Bugsink Alert

ErrorException: Warning: filesize(): stat failed for /srv/www/www.verl.de/pages/public/uploads/tx_powermail/itznkdznkr

Automatisch erstellt durch n8n

KI-Analyse:

Analyse: Warning: filesize(): stat failed¶

1. Ursache identifiziert¶

Datei existiert nicht auf dem Dateisystem.

filesize() schlägt mit stat failed fehl, wenn die übergebene Datei nicht (mehr) existiert oder für den PHP-Prozess nicht lesbar ist (z. B. fehlende Berechtigungen, defekter Symlink, Pfad ist ein Verzeichnis, Race Condition nach Cleanup).

Pfad-Kontext: /srv/www/www.verl.de/pages/public/uploads/tx_powermail/itznkdznkr

• Der Pfad liegt unter uploads/tx_powermail/ — das ist ein temporärer Upload-Pfad der Extension powermail (In2code). itznkdznkr ist der typische verschlüsselte temporäre Dateiname (Hash) für ein hochgeladenes Attachment während der Formularbearbeitung.
• Der Fehler tritt während des HTTP-Requests auf, bevor Middleware-Business-Logik überhaupt durchlaufen wird (siehe Stack: VerifyHostHeader → NormalizedParamsAttribute → ResponsePropagation sind nur Standard-Middleware).

Das bedeutet sehr wahrscheinlich: Der Fehler wird im Konstruktor/Service-Container-Build einer Middleware oder einem Hook ausgelöst, der beim Request-Setup (z. B. tsfe / pageRenderer / TypoScriptFrontendController Initialization) prüft, ob bereits ein Upload mit diesem Hash existiert. Die Datei wurde zwischenzeitlich bereinigt (z. B. durch einen Cleanup-Job, abgelaufene Session, oder weil die lifetime für Temp-Files überschritten ist), aber der Hash wird noch in Session/Formular-Daten referenziert.

2. Fix (konkret)¶

Kurzfristig (Hotfix, verhindert das Warning)¶

Im PHP-Code, der filesize() aufruft, eine Existenz-Prüfung voranstellen:

// VORHER
$size = filesize($path);

// NACHHER
$size = is_file($path) ? filesize($path) : 0;
// oder mit @-Suppressor nur falls Logging nicht gewünscht

Außerdem error_reporting bzw. die ExceptionHandlers Konfiguration in TYPO3 prüfen, damit Warnings nicht als ErrorException hocheskaliert werden — eigentlich sollten das nur Notices/Warnings sein und nicht die Response abbrechen.

Mittelfristig (Ursache beheben)¶

1. Powermail-Konfiguration prüfen:

   • plugin.tx_powermail.settings.misc.uploadFolder — Existiert das Verzeichnis und ist es beschreibbar?
   • plugin.tx_powermail.settings.misc.uploadLifetime — Wie lange bleiben Temp-Files?

2. Cleanup konfigurieren: In typo3conf/localconf.php bzw. LocalConfiguration.php:

   // Stille Errors unterbinden
   $GLOBALS['TYPO3_CONF_VARS']['SYS']['displayErrors'] = 0;
   $GLOBALS['TYPO3_CONF_VARS']['SYS']['errorHandler'] = \TYPO3\CMS\Core\Error\ErrorHandler::class;
   $GLOBALS['TYPO3_CONF_VARS']['SYS']['errorHandlerErrors'] = E_ALL & ~E_NOTICE & ~E_WARNING & ~E_DEPRECATED;
   

3. Upload-Ordner prüfen:

   ls -la /srv/www/www.verl.de/pages/public/uploads/tx_powermail/
   # Existiert der Ordner? Sind Schreibrechte gesetzt?
   # Owner sollte www-data / php-fpm user sein
   

4. In Powermail-Quellcode suchen, wo filesize() aufgerufen wird und diesen Patch dort einreichen (Extension powermail, oft in Classes/Domain/Service/UploadService.php o. ä.).

Falls der Fehler nach Deployment einer konkreten Änderung auftrat¶

• Git-Diff auf Powermail-Dateien prüfen
• Cronjobs für typo3 tempfile:cleanup prüfen — läuft der zu aggressiv?

3. Betroffene TYPO3-Extension¶

In2code Powermail (tx_powermail)

Der Pfad uploads/tx_powermail/ ist eindeutig der von der Extension powermail registrierte Upload-Ordner für temporäre Uploads während des mehrstufigen Formularprozesses.

4. Confidence¶

75%

Begründung:

• ✅ Pfad-Konvention uploads/tx_powermail/ ist eindeutig → Powermail
• ✅ filesize(): stat failed ist eine sehr spezifische Ursache (Datei nicht vorhanden)
• ⚠️ Stacktrace zeigt nur Middleware-Kette — der eigentliche filesize()-Aufruf liegt sehr wahrscheinlich in einem Hook/Initializer, der durch die Middleware getriggert wird. Ohne den genauen Frame des filesize()-Aufrufs ist 100% nicht erreichbar. Den vollen Stacktrace (insbesondere unterhalb von ResponsePropagation) bräuchte es, um den exakten Call-Site in Powermail zu benennen.