Bug #50871
Remove option to delete a File Storage
Status: | New | Start date: | 2013-08-07 | |
---|---|---|---|---|
Priority: | Should have | Due date: | ||
Assigned To: | - | % Done: | 0% |
|
Category: | - | Spent time: | - | |
Target version: | - | |||
TYPO3 Version: | 6.2 | Is Regression: | No | |
PHP Version: | Sprint Focus: | On Location Sprint | ||
Complexity: | medium |
Description
Currently it doesn't make sense you can delete a storage.
When you delete a storage there is no check if there are still files in uses of this storage.
So everywhere where a reference to a sys_file of the deleted storage is present you get a Exception.
Related issues
Associated revisions
[BUGFIX] Files to FileStorage relations are now recorded in sys_refindex
When a file (sys_file) is added/modified/deleted,
the relation to the file storage (sys_file_storage)
is recorded and updated in sys_refindex
Resolves: #64631
Related: #50871
Releases: master, 6.2
Change-Id: If95fac13c5530041948b3f9c896ebb390c31956a
Reviewed-on: http://review.typo3.org/36412
Reviewed-by: Frans Saris <franssaris@gmail.com>
Tested-by: Frans Saris <franssaris@gmail.com>
Reviewed-by: Ingo Schmitt <is@marketing-factory.de>
Tested-by: Ingo Schmitt <is@marketing-factory.de>
Reviewed-by: Anja Leichsenring <aleichsenring@ab-softlab.de>
Tested-by: Anja Leichsenring <aleichsenring@ab-softlab.de>
[BUGFIX] Files to FileStorage relations are now recorded in sys_refindex
When a file (sys_file) is added/modified/deleted,
the relation to the file storage (sys_file_storage)
is recorded and updated in sys_refindex
Resolves: #64631
Related: #50871
Releases: master, 6.2
Change-Id: If95fac13c5530041948b3f9c896ebb390c31956a
Reviewed-on: http://review.typo3.org/36486
Reviewed-by: Anja Leichsenring <aleichsenring@ab-softlab.de>
Tested-by: Anja Leichsenring <aleichsenring@ab-softlab.de>
History
#1 Updated by Oliver Hader almost 2 years ago
If we see a storage as a definition to connect a folder of the physical file system with the TYPO3 file abstraction layer, then we still might allow to remove the storage definition, however should catch the exceptions - or add an option to the install tool to remove a storage, it's sys_file records (not the actual files), sys_file_references and processed files.
#2 Updated by Andreas Wolf about 1 year ago
- Status changed from New to Accepted
- Is Regression set to No
I just had this case while debugging a broken installation. I think the DataMapper should check in a hook that no files are still in use from that storage (or we disallow deletion completely if that's possible).
#3 Updated by Frans Saris 6 months ago
- Sprint Focus set to On Location Sprint
#4 Updated by Ingo Schmitt 6 months ago
- Complexity set to medium
#5 Updated by Philipp Gampe 6 months ago
- Status changed from Accepted to In Progress
#6 Updated by Alexander Opitz 6 months ago
I think, we should left the possibility to delete storages, for example if you moved from a local to a remote storage (or vice versa). Maybe first we need to define scenarios.
But maybe this scenarios lead to a "FAL Management Extension" which is more for admins and not editors (like media).
#7 Updated by Philipp Gampe 6 months ago
I also think that deleting orphaned storages should be possible.
#8 Updated by Gerrit Code Review 6 months ago
- Status changed from In Progress to Under Review
Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/36456
#9 Updated by Gerrit Code Review 6 months ago
Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/36456
#10 Updated by Philipp Gampe 6 months ago
- Category deleted (
File Abstraction Layer (FAL)) - Status changed from Under Review to Accepted
The solution here is to deny deletion of any record which is still referenced.
This would also solve #55714
#11 Updated by Philipp Gampe 6 months ago
- Status changed from Accepted to New