Bug #67554

Deleting Files which are "missing" is not possible

Added by Steffen Ritter over 3 years ago. Updated over 3 years ago.

Status:
New
Priority:
Should have
Assignee:
-
Category:
File Abstraction Layer (FAL)
Target version:
-
Start date:
2015-06-17
Due date:
% Done:

0%

TYPO3 Version:
6.2
PHP Version:
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

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.

History

#1 Updated by Christian Reiter over 3 years ago

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.

#2 Updated by Steffen Ritter over 3 years ago

  • 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.

#3 Updated by Christian Reiter over 3 years ago

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.

Also available in: Atom PDF