Bug #62489
FE : “Desired storage is not in the list of available storages”
Status: | Closed | Start date: | 2014-10-27 | |
---|---|---|---|---|
Priority: | Should have | Due date: | ||
Assigned To: | - | % Done: | 0% |
|
Category: | File Abstraction Layer (FAL) | Spent time: | - | |
Target version: | - | |||
TYPO3 Version: | 6.2 | Is Regression: | No | |
PHP Version: | 5.3 | Sprint Focus: | On Location Sprint | |
Complexity: |
Description
After recreation of "File storage" objects, the Front End doesn't work anymore, "online" link points me [here] : http://wiki.typo3.org/Exception/CMS/1314085990
In BE "fileadmin" folder is browserable, we could read/download files.
Anyone experienced such problem ?
Thx.
Related issues
History
#1 Updated by Hubertus Golf 9 months ago
#2 Updated by Alexander Opitz 9 months ago
@reporter
As I understand you, you removed the file storage and created a new one on the same directory?
#3 Updated by Fedir RYKHTIK 9 months ago
@Hubertus : Great ! That's it. As in my case it was empty Introduction Package installation, I just made TRUNCATE of sys_file. And error dissapeared, except some missing images in FE.
@Alexander Exactly.
#4 Updated by Christian Ludwig 9 months ago
We had the same problem.
A solution would be to delete all relations to that storage in the database (including the meta and processed tables) plus the _ processed _ folders. IMHO the original files themselves should not be deleted. Ideal would be a warning if relations to the files / directories on this storage exist in one or more content elements.
#5 Updated by Alexander Opitz 9 months ago
@Christian
Then you will missing the relations from content elements to the files. Sounds not cool.
@Reporter
To prevent this scenario, I would change this issue in something like: "Do not delete Storage if it contains files." Would this be ok for you? Couse fixing this issue after deletion isn't possible.
#6 Updated by Mathias Schreiber 7 months ago
- Sprint Focus set to On Location Sprint