Feature #80523

Action "replace file" in nested File Storage leads to missing file references

Added by Christoph Dörfel over 4 years ago. Updated over 2 years ago.

Should have
File Abstraction Layer (FAL)
Target version:
Start date:
Due date:
% Done:


Estimated time:
PHP Version:
Sprint Focus:


This is not really a bug and more than anything the result of a configuration mistake. BUT the side effects are rather irritating and nothing warns you about the (probable) misconfiguration.

To reproduce the issue, you have two File Storage spaces (not File Mounts):
- fileadmin/ (auto-created) (ID: 1)
- fileadmin/redaktion (ID: 2)

Add files to a content element (or any record for that matter) from the File Storage with ID 2 (this is what a user of type editor would do).
Now use the file replace action while in File Storage with ID 1 (most likely what an admin user would do) WITH the option "keepfiletitle" disabled (you want to replace the file name).

The file that you just replaced is the same for File Storage 1 & 2 but now all file references for File Storage 2 link to the (now missing) previous file name.

The behaviour is expected. TYPO3 does not check whether file storages are nested and only checks file references for the current file storage. With this in mind, nested file storages should not be allowed (this is what File Mounts are for) OR some form of additional check should look for files with the same hash in different storage locations and throw an exception or at least give some kind of warning.

What do you think about this? Nested storages are possible but lead to bugs when not used correctly. Are additional checks useful / necessary?

Related issues

Related to TYPO3 Core - Task #50796: Prevent creating a FAL storage that is a subfolder of another storageClosedMarc Bastian Heinrichs2013-08-05


Updated by Frans Saris over 4 years ago

Indeed we should me sure there is no nested storage created.

Nested storages are not supported


Updated by Susanne Moog over 2 years ago

  • Tracker changed from Bug to Feature

Updated by Susanne Moog over 2 years ago

  • Related to Task #50796: Prevent creating a FAL storage that is a subfolder of another storage added

Updated by Susanne Moog over 2 years ago

  • Status changed from New to Closed

I'm closing this issue as the base issue is #50796 where the same behaviour is explained. When fixing the other one, this one will be automatically be solved, too.

Also available in: Atom PDF