Bug #67554
closed
Deleting Files which are "missing" is not possible
Added by Steffen Ritter almost 9 years ago.
Updated about 5 years ago.
Category:
File Abstraction Layer (FAL)
Description
once you issue a "getFile" which not physically existent anymore you will get a FileObject with "isMissing" true.
As soon as you try to delete that file Storage::deleteFile($object) there is an IO Exception thrown, because the missing flag is not evaluated.
Solution:
In terms the physical file already is missing, just emit the post-deletion signal so the records are cleaned up.
I would prefer to not remove records for missing files.
It would be better to properly handle the missing status.
Scenario:
- We have a FAL indexed file
x:folder/filename with several sys_file_references pointing to it.
- It is moved by an external script to
x:folder2/newfilename - or it is deleted and created in different place with same content
- Real life example: Sync of a storage from Sharepoint
- The sys_file record gets "missing" set on next access.
- The references of course will be "broken".
- However, as soon as the indexer discovers "folder2/newfilename" a new sys_file record is generated which has the same SHA1 as an existing sys_file_record.
- While the core does not do this, it is very easy for an extension to recognize the situation and for instance "repair" the references.
If we just drop the sys_file record when we find the associated filesystem resource is gone, the option of repair is no longer available.
- Description updated (diff)
Christian Reiter wrote:
I would prefer to not remove records for missing files.
...
If we just drop the sys_file record when we find the associated filesystem resource is gone, the option of repair is no longer available.
Who said anything about deleting them (automatically).
This bug is about the fact that you might have some cleanup code which triggers either
File::delete or Folder::deleteFile which results in ResourceStorage::deleteFile
This does not work depending on the ExceptionLevels configured since.
But if code explicitly wants to remove a file, which already is gone, so the only thing left to do ist removing the sys_file entry, than this should work.
Steffen Ritter wrote:
But if code explicitly wants to remove a file, which already is gone, so the only thing left to do ist removing the sys_file entry, than this should work.
No question at all about that.
- Status changed from New to Closed
Current code checks physical file existence before trying to delete. This was fixed in #67432
- Related to Bug #67432: Deletion of file /typo3temp/_processed_/xy.jpg failed. added
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by