Bug #97486
Updated by Sybille Peters over 1 year ago
* Directories which have filemounts pointing to them (or to a child page) should not be able to be deleted * If the directory is renamed, the directory in the file mounts (and file mounts with child directories) should be renamed as well Given the following situation: * Complex access system of groups / filemounts with filemounts within filemounts e.g. <pre> - fileadmin -> dir1 -> dir1.1 </pre> - group1 - uses filemount for dir1 - group1.1 - uses filemount for dir1.1 Now users in group1 (and admin) could rename the directory dir1.1 (or delete it if no files with references in it). If that happens, the user in group 1.1 can no longer access the files. Users in group1 may not be aware of the subgroups. There is no warning, when doing this. h2. My suggestion: * it should not be possible by users to delete directories with filemounts (and also with filemounts attached to subdirectories) * directories with filemounts should be marked in filelist so they are visible as "system folder" (and ideally visible as directory with a filemount for admins) * If it is allowed for the directories with filemounts pointing to them (or to child directories) are allowed to be renamed, the file mounts records (sys_file_mount) should be updated as well. h2. TYPO3 versions I reproduced this in v10, superficially confirmed in latest master v12. h2. sys_filemounts - base (int), is storage - path (varchar), is relative path in storage (not uid) Thus, sys_filemounts uses the path, not the uid(s) of dirs / Folders (and AFAIK there is no management of folders by uid anyway). See also note in Folder class: <pre> /** The identifier of this folder to identify it on the storage. * On some drivers, this is the path to the folder, but drivers could also just * provide any other unique identifier for this folder on the specific storage. * * @var string */ protected $identifier; </pre>