[TYPO3-core] FAL: How should legacy-storage be correctly updated?

[Stefan Neufeind]

Hi,

basis for this email is a problem between using legacy-storage and the
default fileadmin-storage. But part of it also apply to other storages
as well, especially in case some of them overlap.


I digged into a case where sys_file contained outdated information for a
file. The most obvious wrong part was width/height were not correct so
TYPO3 generated an img-tag with wrong parameters.

In the TypoScript-template the file was embedded like this:

logo = IMAGE
logo.file = fileadmin/template/logo.png

So the legacy-storage (storage-ID 0) was used to retrieve data. The file
was changed but the repository didn't notice it.

If the file would have been changed outside of TYPO3 I could well
understand TYPO3 didn't know about the change. And for
performance-reasons TYPO3 didn't check over and over again if the file
is still current.

But the file was even updated using the Filelist-module.


The problem occurs since the default file-storage (ID 1; fileadmin;
auto-created) that can be accessed through the Filelist-module tracks
the file separately - relative to it's own base (fileadmin).


The easy way to solve this problem was to use the default file-storage
also in the TypoScript-template:

logo.file = 1:template/logo.png


But I wonder how we could maybe resolve this issue and, to the FAL-gurus
maybe, which kind of a patch would fit best. Solutions I see:


1) Upon file-change in a storage-driver notify other drivers
When updating the file using the filelist-module in the local
default-storage (ID 1; base-path fileadmin/) this would mean upon
adding/updating/... a file we'd see which other repositories of same
type exist, find out their basepath (and adjust relative path of file)
and notify those storages about the updated properties as well.

This would however imho only work cleanly/easily for the "Local"-driver.
Another "problem" is also that the StorageRepository when doing a
findByStorageType() would not return the legacy-storage (ID 0) since
it's only "virtual" and does not exist in the database.

But would it be realistic (despite this special case with storage 0 and
1) to expect to have multiple storages that just have different
base-paths and overlap? Especially when it comes to cases with virtual
paths (links in filesystem, remote-storages with certain fileshares
and/or login-credentials used) there would still be cases we can't
cleanly determine which other storages to notify.


2) Performing basic checks on files after fetching a FileIndexRecord.
For performance-reasons imho we can't perform sha1-checks. But would
basic checks for size and modification_date maybe be possible? This way
we could notice an outdated record at least so information can be
fetched again.


3) Use legacy-storage as few as possible?
When trying to load a file from legacy-storage, might it be an option to
search for the "best matching" local driver first (longest match on
path)? In this case here it could have been detected the file used was
under fileadmin/ and we could have used that storage (ID 1) instead of
using our legacy-storage.


Kind regards,
 Stefan