Bug #50871

Remove option to delete a File Storage

Added by Frans Saris over 8 years ago. Updated over 5 years ago.

Status:
New
Priority:
Should have
Assignee:
-
Category:
Backend User Interface
Start date:
2013-08-07
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
6.2
PHP Version:
Tags:
Complexity:
medium
Is Regression:
No
Sprint Focus:
Remote Sprint

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

Related to TYPO3 Core - Task #64617: Don' change configuration of filestorage if files are presentAccepted2015-01-29

Actions
Related to TYPO3 Core - Bug #64631: Relations between files(sys_file) and file storage(sys_file_storage) are not recoreded in sys_refindexClosed2015-01-30

Actions
Related to TYPO3 Core - Bug #55714: Not available storages assigned to user shouldn't cause "hard failure"ClosedGeorg Ringer2014-02-06

Actions
Has duplicate TYPO3 Core - Bug #62489: FE : “Desired storage is not in the list of available storages”Closed2014-10-27

Actions
#1

Updated by Oliver Hader over 8 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 over 7 years 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 almost 7 years ago

  • Sprint Focus set to On Location Sprint
#4

Updated by Ingo Schmitt almost 7 years ago

  • Complexity set to medium
#5

Updated by Philipp Gampe almost 7 years ago

  • Status changed from Accepted to In Progress
#6

Updated by Alexander Opitz almost 7 years 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 almost 7 years ago

I also think that deleting orphaned storages should be possible.

#8

Updated by Gerrit Code Review almost 7 years 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 almost 7 years 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 almost 7 years 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 almost 7 years ago

  • Status changed from Accepted to New
#12

Updated by Anja Leichsenring over 6 years ago

  • Sprint Focus changed from On Location Sprint to Remote Sprint
#13

Updated by Riccardo De Contardi over 5 years ago

  • Category set to Backend User Interface
  • Target version set to Candidate for Major Version

Also available in: Atom PDF