Bug #67554

Deleting Files which are "missing" is not possible

Added by Steffen Ritter almost 4 years ago. Updated about 2 months ago.

Status:
Closed
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.


Related issues

Related to TYPO3 Core - Bug #67432: Deletion of file /typo3temp/_processed_/xy.jpg failed. Closed 2015-06-13

History

#1 Updated by Christian Reiter almost 4 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 almost 4 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 almost 4 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.

#4 Updated by Susanne Moog about 2 months ago

  • Status changed from New to Closed

Current code checks physical file existence before trying to delete. This was fixed in #67432

#5 Updated by Susanne Moog about 2 months ago

  • Related to Bug #67432: Deletion of file /typo3temp/_processed_/xy.jpg failed. added

Also available in: Atom PDF