[TYPO3-core] FAL: why does ResourceStorage->getRootLevelFolder() return filemouts instead of real root folder?

[Franz Koch]

> well, title says it all - why does the getRootLevelFolder function of
> ResourceStorages return the first filemount folder for users instead of
> always returning what it's supposed to by it's naming and return the
> real root folder? What was the intention behind this? IMO filemount
> logic must not be part of that function.

Some more background info why I'm asking. I currently need to determine 
the real rootfolder of a storage because I need to update file paths in 
the DB on rename by using the 
\TYPO3\CMS\Core\Utility\File\ExtendedFileUtilityProcessDataHookInterface 
hook (needs to be backwards compatible to older TYPO3 versions, that's 
why I use the hook instead of signals).

Issue now is, that the arguments passed to this hook are the combined 
FAL identifiers and not the full relative paths in case of the local 
driver. But to update my db fields I have to convert "1:foo.bar" to 
"fileadmin/baz/foo.bar" where "fileadmin/baz/" is supposed to be the 
root folder of the storage itself (not a mount). And because the folder 
(or file, doesn't matter) does no longer exist in the storage I'm no 
longer able to ask the factory or storage to create an object for the 
old file/folder name (will throw an exception) and get the publicUrl via 
the driver from there.

So all I can do is to get an instance of the ResourceStorage by it's uid 
and ask it for the rootfolder. But now, this function is returning some 
mountpoints folder instead of the rootfolder - wtf? So it seems there is 
no sane way using the APIs to convert a combined identifier from a 
moved/renamed resource to the full qualified path. Or am I missing 
something?

-- 
kind regards,
Franz Koch