Bug #45110

File is listed twice in sys_file

Added by Philipp Gampe over 2 years ago. Updated over 1 year ago.

Status:Closed Start date:2013-02-03
Priority:Should have Due date:
Assigned To:- % Done:

0%

Category:File Abstraction Layer (FAL) Spent time: -
Target version:6.1.0
TYPO3 Version:6.0 Is Regression:No
PHP Version: Sprint Focus:
Complexity:

Description

I do not know how this can happen, but I had two different file entries for the same file in sys_file.

I create this bug report, so that we can track those kind of incidents. This could result in strange behaviors.

112    0    1359812815    1359812407    0    1    0    0    0        0    0    0    0    0    0    5    1    /templates/2013/news_v3.css    css    application/x-empty    news_v3.css    NULL    da39a3ee5e6b4b0d3255bfef95601890afd80709    0    1359815618    1359815618    0    0    NULL    NULL
113    0    1359816267    1359816286    0    0    0    0    0        0    0    0    0    0    0    1    1    /templates/2013/news_v3.css    txt    text/x-c    news_v3.css    NULL    dd6aa8a65e99cf98441d5c6d044fd2a5c168ee91    7552    1359816267    1359816267    0    0    NULL    NULL

Related issues

related to Core - Bug #45109: Editing the file content of a file marked as deleted resu... Closed 2013-02-03
blocked by Core - Bug #34160: Replacing/Overwriting a file could leave a stale index re... Closed 2012-02-21

History

#1 Updated by Alexander Opitz over 2 years ago

Is it possible that you renamed the file before, as described in #34160?
Or could it be that you deleted the file previously and re added it, so it could be #44550?

#2 Updated by Andreas Wolf over 2 years ago

  • Status changed from New to Accepted
  • Target version set to 6.1.0

There is a possibility that an existing file record is not used if a file is moved. I know of this bug and we definitely have to solve it. However, I'd first like to discuss what should happen to existing records and esp. relations to them.

Imagine the following situation: Two files, identifiers /fileA and /fileB, both indexed. /fileA is now moved to /fileB, destroying the original fileB. In that case, we would have to throw away the record of fileB. This in turn would lead to dangling relations if fileB was used before.

Therefore, we have to handle this case both on the higher abstraction levels (i.e. where relations are managed) and on the low-level side (i.e. where files and their index records are managed). The latter is already there, though a bit buggy. The former has not at all been taken care of until now.

#3 Updated by Steffen Ritter over 1 year ago

  • Status changed from Accepted to Needs Feedback
  • Is Regression set to No

this is storage 0 reindexation, problems should be solved by now...

#4 Updated by Philipp Gampe over 1 year ago

It does not happen in master for moving files any more. I suggest to close this issue and reopen the it if something like this happens again.

p.s.: I cannot close issues here.

#5 Updated by Alexander Opitz over 1 year ago

  • Status changed from Needs Feedback to Closed

Also available in: Atom PDF