TYPO3 Core

I just tested it with 6.1.1 and 6.2 and can confirm that it is somehow fixed in 6.2.
Although I have no idea where, since the involved files RteHtmlParser and ResourceFactory did not change in relevant parts.

Maybe the change happened somewhere else in FAL? (Perhaps a case for git-bisect)

I was wrong, the bug is not yet fixed!

The problem is:
The parser calls ResourceFactory->retrieveFileOrFolderObject($input) where input is the filepath.
The comment says: input can be "uploads/myfile.png" (backwards-compatibility, storage "0")

Thus the file is added with storage 0 and "lost". No idea how storage with uid 0 should be handled...

It happens when opening a content element containing a file link with a not converted reference like
<link fileadmin/download/myfile.txt >Download</link> in the backend.

Then the RteHtmlParser->TS_links_rte converts the link into a FAL reference by calling ResourceFactory->retrieveFileOrFolderObject as described above and a sys_file entry with storage 0 is added.

With the RteFileLinksUpdateWizard Francois pushed yesterday to gerrit https://review.typo3.org/#/c/22002/ such links should not occur anymore after migration, but it should be fixed anyway. Perhaps with the same routine as in the Wizards.

I can reproduce it with a 6.1.1 installation.
Just add a new content element text w. image to a page, add a new image (best upload it in the window). As soon as you do a preview of the page, the image is added again to the sys_file table without any storage (already in it with storage 1). As you can see of the DB dump below, two identical entries are in the sys_file table, one with storage 1 (fileadmin) and the other with storage 0 and fileadmin prepended.

INSERT INTO `sys_file` (`uid`, `pid`, `tstamp`, `crdate`, `cruser_id`, `deleted`, `t3ver_oid`, `t3ver_id`, `t3ver_wsid`, `t3ver_label`, `t3ver_state`, `t3ver_stage`, `t3ver_count`, `t3ver_tstamp`, `t3ver_move_id`, `t3_origuid`, `type`, `storage`, `identifier`, `extension`, `mime_type`, `name`, `title`, `sha1`, `size`, `creation_date`, `modification_date`, `width`, `height`, `description`, `alternative`) VALUES
(1805961, 0, 1373027842, 1373027842, 1, 0, 0, 0, 0, '', 0, 0, 0, 0, 0, 0, '2', 1, '/user_upload/amd_richland_a6.jpg', 'jpg', 'image/jpeg', 'amd_richland_a6.jpg', NULL, '5e08dfb45f9dc4aca9ce71cbe0c3562604938cdf', 159303, 1373183468, 1373183468, 803, 1080, NULL, NULL),
(1806193, 0, 1373183551, 1373183551, 0, 0, 0, 0, 0, '', 0, 0, 0, 0, 0, 0, '2', 0, '/fileadmin/user_upload/amd_richland_a6.jpg', 'jpg', 'image/jpeg', 'amd_richland_a6.jpg', NULL, '5e08dfb45f9dc4aca9ce71cbe0c3562604938cdf', 159303, 1373183468, 1373183468, 803, 1080, NULL, NULL);

Btw it also happens for old extensions that still use the uploads directory, the sys file is added when previewed.

still happening with 6.1.5 all the time (and therefore breaking our replication every day)

looked into it closer now, I cant reproduce it with 6.1.5 (therefore the above mentioned case wont happen anymore), but still the replication broke a couple of times due to sys_file items created on the frontend server. Will look into it and update this as soon as it happens again and I find out more.