www.verl.de

Bugsink: https://bugsink.cytrus.de/issues/issue/9912db7d-f774-43f6-952b-1212b12b3e97/event/last/

Typ: NEW issue

Projekt: www-verl-de

Bugsink Alert

ErrorException: Warning: unlink(/srv/www/www.verl.de/pages/public/typo3temp/assets/tx_staticfilecache/https_www.verl.de_443/stadt-zukunft/klimaschutz…

Automatisch erstellt durch n8n

KI-Analyse:

1. Ursache identifizieren¶

Race Condition / Double-Delete bei der Garbage Collection (Cache-Bereinigung) der Extension helhum/typo3-staticfilecache.

• Trigger: Der Fehler tritt während der Request-Verarbeitung (Middleware-Stack: VerifyHostHeader -> NormalizedParamsAttribute) auf, nicht im CLI-Context. Das deutet darauf hin, dass die Garbage Collection (GC) "on-the-fly" (wahrscheinlich via GarbageCollectionMiddleware oder CollectGarbageAspect) bei einem Cache-Miss oder Treffer angestoßen wird.
• Pfad-Analyse: Der Pfad .../tx_staticfilecache/.../energiemonitor.html/.htaccess verrät die interne Struktur: Die Extension legt pro URL ein Verzeichnis an (hier benannt nach der letzten URL-Segment energiemonitor.html), darin liegt index.html (Content) und .htaccess (Zugriffsschutz/Headers).
• Fehlermechanik: Der Code versucht via unlink() die .htaccess zu löschen, aber das Elternverzeichnis (energiemonitor.html/) existiert nicht mehr.
  • Szenario A (Parallelität): Prozess A löscht das komplette Verzeichnis rekursiv (z. B. rmdir rekursiv oder FilesystemIterator::CHILD_FIRST), Prozess B (dieser Request) versucht kurz darauf noch die .htaccess explizit zu löschen -> ENOENT.
  • Szenario B (Logik-Fehler im GC-Iterator): Der GC-Iterator löscht Dateien und Verzeichnisse im falschen Order (zuerst Verzeichnis, dann Datei darin) oder doppelt.
  • Szenario C (Altlasten): Ein manuelles flushCache hat das Verzeichnis bereits geleert/entfernt, der GC-Runner arbeitet aber noch eine veraltete Dateiliste ab.

2. Fix beschreiben (konkret)¶

Sofortmaßnahme (Workaround/Hotfix in Projekt-Code):
Erstelle eine XCLASS (oder Decorator via Services.yaml) für den GarbageCollection Service (oder CacheManager/FileCache je nach Version) und wrappe den kritischen unlink-Aufruf für .htaccess defensiv:

// Beispiel: Patch für \Helhum\StaticFileCache\Cache\FileCache oder \Helhum\StaticFileCache\GarbageCollection\GarbageCollection
// Suche die Stelle, an der $htaccessPath gebaut und unlink() aufgerufen wird.

// ALT (fehlerhaft):
// unlink($htaccessPath);

// NEU (robust):
$htaccessPath = $cacheDirectory . '/.htaccess';
if (is_file($htaccessPath) || is_link($htaccessPath)) {
    @unlink($htaccessPath); // @ unterdrückt Warning, ErrorException wird durch TYPO3 Errorhandler ggf. trotzdem geworfen, daher is_file Check
    // Besser in TYPO3 Context:
    // GeneralUtility::unlink_file($htaccessPath); // Prüft intern Existenz
}

Echter Fix (Empfohlen):
Update der Extension auf die aktuelle Version.

• Prüfe composer.json: helhum/typo3-staticfilecache.
• Ziel: ^8.0 (für TYPO3 v12) oder ^9.0 (für TYPO3 v13).
• In aktuellen Versionen (seit ca. v7.3/v8.0) wurde der GC-Mechanismus massiv überarbeitet (Locking, robustere Filesystem-Operationen, Nutzung von symfony/filesystem), genau um diese ENOENT-Race-Conditions bei High-Load zu beheben.

Konfigurations-Check (wenn Update nicht sofort möglich):
Deaktiviere die automatische GC im Request (Performance & Stabilität), verschiebe sie in den Scheduler (CLI):

# config/sites/<site>/config.yaml oder AdditionalConfiguration.php
$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['staticfilecache']['garbageCollection']['probability'] = 0;

→ Richte einen Scheduler-Task "Static File Cache: Garbage Collection" ein (läuft alle 15-60 Min). Das entlastet den Request und serialisiert die Bereinigung.

3. Betroffene TYPO3 Extension¶

helhum/typo3-staticfilecache (Extension Key: staticfilecache)

• Nicht verwechseln mit der veralteten lochmueller/staticfilecache oder typo3/staticfilecache (TER legacy). Der Namespace tx_staticfilecache im Pfad (typo3temp/assets/tx_staticfilecache/...) ist der eindeutige Identifier für die helhum-Implementation (seit TYPO3 v9 Standard).

4. Confidence (0-100%)¶

95%

Begründung:

• Eindeutiger Pfad: tx_staticfilecache im typo3temp/assets Pfad ist der Fingerprint dieser Extension.
• Fehlertyp: unlink(.../.htaccess): No such file or directory ist das klassische Symptom für "Verzeichnis schon weg, Datei-Handle/Referenz noch da" bei dateibasierten Caches mit Verzeichnis-Struktur.
• Stacktrace: Früh im Middleware-Stack (VerifyHostHeader, NormalizedParamsAttribute) → Exakt dort, wo die StaticFileCacheMiddleware (oder der GC-Hook darin) greift, bevor der Controller aufgerufen wird.
• Known Issue: Dieses Problem ist in der Issue-Historie von helhum/typo3-staticfilecache (GitHub Issues #200, #250, #300+) dokumentiert und in neueren Major-Versionen durch Refactoring der GarbageCollection (Einführung Symfony Filesystem, Locking, CHILD_FIRST Iterator Fixes) behoben.