IRSS Storage Audit — Components Still Storing Files Outside the IRSS

Goal: map which ILIAS components still persist/read files by legacy means (ilFileSystemGUI, ilFileUtils/ilUtil, raw PHP fopen/file_put_contents/mkdir, or ILIAS\Filesystem used directly) instead of routing all binary content through the IRSS (ILIAS Resource Storage Service), which is meant to become the single storage entry point.

Scope: all 182 dirs under components/ILIAS/. Generated by a per-component grep signal matrix followed by a domain-grouped read of every component with a file-storage signal. Branch: trunk (ILIAS 12.0_alpha). Date: 2026-07-02.

⚠ Note: This report was AI-generated and may deviate from reality. Component classifications, verdicts, effort estimates and file:line references reflect an automated audit of the code at the time of writing and can contain errors, omissions or stale citations. Verify against the current source before acting on any finding.

How to read this

• IRSS = target. Markers: resourceStorage(), ResourceStorage\, IRSSServices, ResourceBuilder, StorableResource, AbstractResourceStakeholder, a persisted rid column.
• Legacy = anything else that touches disk for persistent domain content:
  1. ilFileSystemGUI (legacy file browser)
  2. ilFileUtils:: / ilUtil:: file helpers (makeDir, moveUploadedFile, getWebspaceDir, delDir, zip, …)
  3. raw PHP fs (fopen, fwrite, file_put_contents, move_uploaded_file, mkdir, copy, unlink, …)
  4. ILIAS\Filesystem service used directly ($DIC->filesystem()->web()/storage()/temp()) — note IRSS uses this service internally, so calling it directly is a bypass.

Architectural ground truth

IRSS never touches disk itself. ResourceStorage orchestrates; it injects a Filesystem $fs into its storage handlers (ResourceStorage/src/StorageHandler/FileSystemBased/AbstractFileSystemStorageHandler.php:54), which wraps league/flysystem's LocalFilesystemAdapter (Filesystem/src/Provider/FlySystem/FlySystemLocalFilesystemFactory.php:68). So Filesystem is the backend, ResourceStorage is IRSS, FileUpload is ingest, VirusScanner is a scan preprocessor, FileDelivery is egress, WebAccessChecker is legacy egress being retired. Everything else is a consumer.

Verdict legend

Master table

Still to migrate — LEGACY (persistent content on disk, no IRSS)

PARTIAL (IRSS for the primary payload, legacy remnants)

MIGRATED (persistent content on IRSS; only transient disk left)

N/A (no own persistent file storage)

INFRA (the storage stack itself)

Shared legacy substrates (fix once, many benefit)

These non-IRSS storage layers are leaned on by multiple components — migrating them unblocks several:

1. ilFileSystemAbstractionStorage — object-id-keyed on-disk tree. Used by: Course (ilFSStorageCourse), StudyProgramme (ilFSStoragePRG), Verification (ilVerificationStorageFile), Mail (ilFSStorageMail), Group (ilFSStorageGroup).
2. Object custom-icon layer (webspace/container_data/obj_<id>, object.customicons.factory). Used by: Container, Category, StudyProgramme (object icon).
3. ilFileUtils toolbox (FileServices/classes/class.ilFileUtils.php) — every ilFileUtils:: call in every component resolves here. It is infrastructure, not a per-component store, but retiring it is the endgame.
4. Export/Import zip build/extract on data dir (ilExport/ilExportContainer/ilImport/ilImportDirectory) — core infra; the disk-based assembly step sits under many components' export features.

Already covered: MediaObjects payload (mobs/mm_<id>) lives in IRSS since ILIAS 10, so the media of Glossary / Wiki / Blog / Portfolio / News / MediaCast / MediaPool already sits in IRSS. Those components only need residual _getDirectory / _getURL call-site cleanup, not a data migration.

Suggested migration priority

Tier 1 — real user content, high value, self-contained-ish - Mail attachments (deeply disk-coupled, but pure user content) - Course attachments - SCORM family (ScormAicc/Scorm2004/CmiXapi) — follow the HTMLLearningModule IRSS-container pattern (migration already scaffolded on branch feature/12/scorm-irss)

Tier 2 — clean, bounded, low effort (good "Poll-style" stakeholder migrations) - OpenIdConnect login image - LTIConsumer provider icons - Verification cert PDFs - LearningSequence intro/extro images - DidacticTemplate icons - Badge pub_badges/

Tier 3 — finish the PARTIALs - TestQuestionPool / Test question images + archiver (largest surface, ~186 sites combined) - Style ilObjStyleSheet legacy path - Certificate portfolio PDF · User exports - StudyProgramme / OrgUnit object icons + member export

Tier 4 — shared substrates & infra - Retire ilFileSystemAbstractionStorage, the Object custom-icon layer, and eventually the ilFileUtils toolbox; stream-ify Export/Import zip handling; drop WebAccessChecker and legacy FileDeliveryTypes.

Not IRSS targets (leave as-is): Saml (bundled lib needs real paths), Language files, Chatroom server config, Authentication domains file, setup probes, DB dumps, logs, caches, and all transient export/zip/temp scaffolding.

Appendix: MediaObjects — detailed IRSS state

MediaObjects payload is stored in IRSS, migrated in the ILIAS 10 cycle (components/ILIAS/MediaObjects/classes/Setup/class.ilMobMigration.php, commit 2d78e5a9628, 2024-10-23, registered in class.ilMediaObjectSetupAgent.php). The mobs/mm_ dir API remains in the code but is no longer the store of record.

What the migration does

• ilMobMigration::step() moves CLIENT_WEB_DIR/mobs/mm_<id> into an IRSS container resource via ilResourceStorageMigrationHelper::moveDirectoryToContainerResource(), persists the rid in mob_data.rid, then deletes the source dir (recursiveRmDir). Empty/absent dirs get rid = '-'.

Runtime is IRSS-first

• Writes — every ingest path routes to the IRSS-backed manager/repo: addMediaItemFromUpload/FromLocalFile/FromLegacyUpload, replaceMediaItemFromUpload, uploadAdditionalFile → MediaObjectManager::addFile* → MediaObjectRepository (IRSS container).
• Reads — MediaObjectManager::getLocalSrc() → repo->getLocalSrc() → irss->getContainerUri($rid, $location) (MediaObjectRepository.php:186). Falls back to a WAC-signed legacy _getURL() path only when the container returns nothing (un-migrated / offline).
• ilObjMediaObject::getXML() IL_MODE_OUTPUT is dual-mode: the // pre irss file branch (class.ilObjMediaObject.php:522-536) uses ilWACSignedPath::signFile() on the legacy disk file only if it still exists, otherwise manager->getLocalSrc() (IRSS). Correct back-compat, not a leak.

Residual legacy call-sites (cleanup, ~6)

Downstream delegators

Glossary / Wiki / Blog / Portfolio / News / MediaCast / MediaPool store their media as media objects, so that content lives in IRSS. Their remaining _getDirectory / _getURL references (e.g. Blog/Posting/class.ilBlogPostingGUI.php:788,806, News/classes/class.ilNewsItem.php:1820, MediaCast/classes/class.ilObjMediaCastAccess.php:154 dirsize, MediaPool/classes/class.ilObjMediaPoolGUI.php:1493 createDirectory) hit the fallback/vestigial path — call-site cleanup, not a data migration.

Net state: MediaObjects payload is on IRSS since ILIAS 10; the only functional gap is exportFiles() + multi-SRT staging still touching the now-removed webspace dir.

Appendix: Export component — detailed IRSS state

On IRSS: the finished export artifact (the completed zip) plus its registry, download and public-access live in IRSS as a container resource owned by the export_handler stakeholder (ExportHandler/Repository/Stakeholder/Handler.php:37), created via manageContainer()->containerFromStream() (ExportHandler/Repository/Wrapper/IRSS/Handler.php:62) and served with consume()->download() (ExportHandler/Repository/Element/Wrapper/IRSS/Handler.php:202-209). The old disk-scanned export_file_info registry was replaced by table export_files(object_id, rid, owner_id, timestamp); a one-off migration ingests each existing on-disk zip into IRSS (Setup/…/ilExportFilesToIRSSMigration.php:97-125, registered Setup/ilExportSetupAgent.php:51).

Still on disk: the zip is assembled on a data-dir "export run dir" first, then streamed into the IRSS container and deleted (ExportHandler/Manager/Handler.php:180-204: makeDirParents → exporters write in → writeDirectoryRecursive → delDir). Even createEmptyContainer builds a temp zip on disk before ingest (Repository/Wrapper/IRSS/Handler.php:52-64). Import extraction is still fully on the data dir (ilImport/ilImportDirectory, the latter injecting ILIAS\Filesystem directly).

One central pipeline, no fallback. ilExportGUI always delegates to the IRSS ExportHandler — class.ilExportGUI.php:285-286 (createXMLExport) and :333-356 (createXMLContainerExport). There is no runtime if(legacy) … else … branch and no feature flag. The legacy ilExport::exportObject()/exportEntity() survive only for a few direct non-GUI callers: Style (class.ilObjStyleSheetGUI.php:414), COPage layout admin (class.ilPageLayoutAdministrationGUI.php:371), LearningModule entity export (class.ilContObjectExport.php:175).

Per-component exporters are reused, not rewritten. Both the new and legacy paths resolve the same il<Component>Exporter (ilXmlExporter subclass) via ilImportExportFactory::getExporterClass (class.ilImportExportFactory.php:29-65; new path at ExportHandler/Manager/Handler.php:73) and call getXmlRepresentation() + head/tail dependency recursion. Binary payloads are emitted by ilDataSet as typed fields (Export/DataSet/class.ilDataSet.php:307-348): - rscollection / rscontainer → copied IRSS-container-to-IRSS-container, no disk (Consumer/ExportWriter/Handler.php:161-165). This is how migrated components (e.g. MediaObjects, File, Forum) export their binaries. - legacy directory / exportFiles() output → still written into the disk run-dir, then ingested.

Standalone exports (plugged into ilExportGUI as export options but managing their own files, mostly disk via ExportHandler/Consumer/ExportOption/BasicLegacyHandler.php:56,87 + deliverFileLegacy, or fully independent): HTML exports (ilCOPageHTMLExport, ilWikiUserHTMLExport, ilSystemStyleHTMLExport, ilHTLMExportOptionHTML), Test (ilTestExportOptionARC, ilTestExportOptionXMLRES), DataCollection (ilDataCollectionExportOptionsXLSX), member exports (StudyProgramme, Membership).

Cross-component gap: ilObjMediaObject::exportFiles() still rCopys from the deleted mobs/mm_<id> dir and is called by the standalone/on-disk exporters of Test, Forum, Survey, LearningModule and TestQuestionPool — so embedded media in those exports can be silently dropped after the mob migration. The central pipeline is unaffected (it uses the rscontainer field).

Migration history by release

When each component's IRSS storage first shipped. Resolved by finding the commit that introduced the component's earliest IRSS anchor (a *Stakeholder class or a Setup IRSS migration) — following file renames across the pre-ILIAS-10 Modules/+Services/ → components/ILIAS/ restructure via git log --follow -S "class <Name>" — then mapping that commit to the earliest release tag that contains it (git tag --contains … | grep '^v(7|8|9|1[0-9])\.[0-9]+$' | sort -V | head -1; the N>=7 filter drops a spurious v3.8 SVN-import tag). The release is authoritative (via tag --contains); the date is the commit's author date, which routinely precedes the release by 1–2 years because features land on trunk long before the release is cut. For components with several stakeholders across releases, this is the earliest one; PARTIAL components added further pieces later and still carry legacy remnants (see the tables above).

IRSS launched in ILIAS 7 with ilObjFile as the pilot, then spread release by release.

ILIAS 7 (v7.0, ~2021)

ILIAS 8 (v8.1, ~2023)

ILIAS 9 (v9.0, ~2024)

ILIAS 10 (v10.0, ~2025)

ILIAS 11 (v11.0, ~2026)

trunk (unreleased — ILIAS 12)

Not yet migrated (no release): every component in the LEGACY table above (Course, ScormAicc, Scorm2004, LearningModule, Survey, SurveyQuestionPool, CmiXapi, Verification, Language, Container, DidacticTemplate, LearningSequence, Saml, OpenIdConnect, LTIConsumer, Authentication, Chatroom, Category, WebServices) has no IRSS migration.