Bug #95122
openTYPO3 falesly indexes file CHANGE time (ctime) into sys_file.creation_date.
0%
Description
Updated description¶
TYPO3 indexes a file's mtime
into sys_file.modification_date, which is correct. The mtime
= modification time of file content.
TYPO3 indexes a file's ctime
into sys_file.creation_date, which is wrong . The ctime
= change time of the file node (including name, access modifiers, and content).
ctime >= mtime, basically always.
The "c" stands for "change", not "creation".
TYPO3 also labels this sys_file.creation_date
field in the backend as "Created At", which is wrong, as it contains semantically the filesystem change time of the file, as noted above.
Original ticket Description¶
Hey guys,
It seems that create date and Last modified date in FAL is reversed (info and ref view.) Checked it in TYPO3 7/8/10.
Cheers,
Andrea
Files
Updated by Christoph Schwob about 3 years ago
Also occurs in current master.
But there it's only on ElementInformation and not on FileList's default view.
Updated by Andreas Kienast about 3 years ago
This is a Linux specialty. Linux (at least the commonly used ext4 file system) doesn't store the actual creation date in a file's metadata in the file system, but the last inode change time, becoming the actual result of filectime()
. With renaming a file, the inode changes as well, thus the "creation date" gets updated in FAL storage as well.
I don't think there's much we can do here but not relying on the dates the file system reports to TYPO3, which requires major rewrites of FAL, AFAICS.
Updated by Andrea Herzog-Kienast about 3 years ago
Jepp, but strange noboby noticed. As I can see: Uploaded file in FAL gets a timestamp, however upload date. If you change the filename LINUX "thinks" - a new file. Changing Metadata doesn't have any influences to date times.
Updated by Urs Braem over 2 years ago
- TYPO3 Version changed from 10 to 11
I can confirm with TYPO3 11 on centOS.
In the databases I looked at,
SELECT name, FROM_UNIXTIME(creation_date) as created, FROM_UNIXTIME(modification_date) as modified
FROM sys_file
WHERE creation_date < modification_date
returns zero or next to it. That means that creation_date is always newer or equal to modification_date (which is the wrong way round, creation_date should stay fixed, while modification_date should be raised sometimes.
Updated by S P 8 months ago
- TYPO3 Version changed from 11 to 12
The core file Indexer
has this:
$mappingInfo = [
// 'driverKey' => 'fileProperty' Key is from the driver, value is for the property in the file
'size' => 'size',
'atime' => null,
'mtime' => 'modification_date',
'ctime' => 'creation_date',
'mimetype' => 'mime_type',
];
The `ctime` field of a file is the CHANGE time, it is NOT the creation time. The TYPO3 core got this totally wrong, since ever. In most file systems an actual creation time of a file is not known.
ctime
(filesystem node change time) gets updates whenever anything regarding the file changes (like name, access modifiers, content, ...).
But mtime
(content modification time) gets only updates when the content changes.
So, usually ctime >= mtime.