Bug #17321

filemtime() [function.filemtime]: stat failed

Added by Andreas Bockhold over 14 years ago. Updated almost 8 years ago.

Should have
Content Rendering
Target version:
Start date:
Due date:
% Done:


Estimated time:
TYPO3 Version:
PHP Version:
Is Regression:
Sprint Focus:


When creating an FCE with TV and nesting an element type "image" within a section the errormessage stated occurs when inserting an image and saving the page content.

Reproduction of this bug:
- Use TV
- Create an FCE with an element type "image" nested within an element type "section"
- Use Page-module, insert an element of your newly created FCE
- Choose an image
- Save the page content

On top it will be shown:
Warning: filemtime() [function.filemtime]: stat failed
for /[path]/typo3/uploads/tx_templavoila//[path]/typo3/fileadmin/media/yourpicture.jpg
in /[path]/typo3/t3lib/class.t3lib_befunc.php on line 1625

Used environment:
Linux, Apache, MySQL
TYPO3 4.1.1
TV 1.3.1
DAM 1.0.11
(issue imported from #M5665)


0005665_4.3_alpha3.patch (2.01 KB) 0005665_4.3_alpha3.patch Administrator Admin, 2009-09-12 12:22
0005565_4.1.12.patch (2.27 KB) 0005565_4.1.12.patch Administrator Admin, 2009-09-12 13:26
0005665_4.3-alpha3_v2.patch (2.01 KB) 0005665_4.3-alpha3_v2.patch Administrator Admin, 2009-09-22 21:53
0005565_4.1.12_v2.patch (2.22 KB) 0005565_4.1.12_v2.patch Administrator Admin, 2009-09-22 21:59

Related issues

Related to TYPO3 Core - Bug #21173: Replace "Warning: filemtime(): stat failed" with a nice error messageClosedRupert Germann2009-10-01

Related to TYPO3 Core - Bug #19716: History/Undo not works on image elementsClosed2008-12-18

Is duplicate of TYPO3 Core - Bug #17079: Wrong path for images in repetitive content elementsClosed2007-03-05


Updated by Gunther Schöbinger about 14 years ago

I got the same problem here and it occurs by selecting the image the first time. After saving the section once, the problem isn't present any more.

Adding a section the first time (by the select-box) the field tx_templavoila_flex of tt_content has still the old structure - and it could be that the image upload crashes with this old structure .

The var $theFile_abs in class.t3lib_befunc.php thumbCode() returns a path like: '/html/uploads/tx_templavoila//html/fileadmin/.....'

TYPO3 4.1.3
TV 1.3.3
no DAM


Updated by Administrator Admin about 14 years ago

At /[path]/typo3/t3lib/class.t3lib_befunc.php, Line 1609 (after "if (trim($theFile)) {") I used the following line of code to delete the PATH_site string from $theFile variable.

$theFile = str_replace(PATH_site,'',$theFile);

I didn't have the time to perform a thorough regression testing, but it seems to be working ok.

TYPO3 4.1.5
TV 1.3.3
DAM 1.0.11


Updated by Franz Holzinger almost 14 years ago

Same problem here with latest TYPO3 4.2.beta

It is impossible to edit with the TCE and save the result due to this warning message. This comes when an image has got lost but is stored in the backend.

Warning: filemtime() [function.filemtime]: stat failed for /var/www/html/uploads/pics/blue2_06.jpg in /var/www/html/typo3_src-4.2.0beta2a/t3lib/class.t3lib_befunc.php on line 1724

Warning: filemtime() [function.filemtime]: stat failed for /var/www/html/uploads/pics/purple_06.jpg in /var/www/html/typo3_src-4.2.0beta2a/t3lib/class.t3lib_befunc.php on line 1724

Make an

and it works fine.


Updated by Dmitry Dulepov over 13 years ago

Franz, @ will hide a message but it will not cure the problem. Is this really what you call "works fine"?


Updated by Franz Holzinger over 13 years ago

This would be another issue to do something better than hiding the message for a not found image.
It is however worst if the TCE backend is blocked by this warning message.


Updated by Chris Bischoff over 13 years ago

I'm getting this error on my system, but with no TV in use or installed.

FreeBSD, Apache, MySQL
Typo3 4.2.1
no DAM
no TV

Can someone please help??


Updated by Nick Lobeck over 12 years ago

This is a duplicate entry of bug http://bugs.typo3.org/view.php?id=5132


Updated by Steffen Kamper over 12 years ago

Franz, it's far from any solution. The question is why filemtime fails - wrong filename, to early call etc. This has to be debugged. As this error seems to occur without TV it looks like a tcemain problem or beFunc.

is there any way to reproduce it all the time?


Updated by Rupert Germann over 12 years ago

I'd say filemtime() IS the solution in this case.
If you look at be_func::thumbCode() you see that getimagesize() (line 1748) has already an
because we can not be shure that the files given in $row[$field] exist at this point.

how can files get lost?
if you do an export/import with records that have files exceeding the limit than these files will be lost when re-importing.


Updated by Nick Lobeck over 12 years ago

No, I'd say @filemtime is not a solution because if you look at the path filemtime receives you can clearly say that this path is wrong. so there must be an error in creating the path to the file ...

This one is still the same bug: http://bugs.typo3.org/view.php?id=5132


Updated by Rupert Germann over 12 years ago

hi Nick,

you're right. It doesn't fix the described bug.
But the filemtime error message can also be caused by other problems (missing file in uploads/) so we should apply the in any case. Without the the BE is not usable when this error occurs.


Updated by Ralf Hettinger over 12 years ago

The error might occur as well, if concurrent editing is in place while editing records that involve image uploading: the uploaded filenames will get appended with _1 _2 _3 etc. correctly after being uploaded, but will be referenced wrongly from the record, since when storing this record, it may not know about a concurrent upload process in th meantime.

So there is not only one reason for this error to occur.

While I agree that the reasons and not the symtpom should be cured, I even more agree that the backend must stay usable for an editor after such an error so that he/she at least can correct such an erroneous behaviuor.

But I disagree with just adding an @ to filemtime: The reasons of those errors might then be considered as solved, which they aren't. And editors won't even recognize, that there is an error and won't see a need for correction although there is.

Attaching a patch, that suggests checking for existance of a thumb file before calling filemtime. If the file doesn't exist, it will add an error message to the corresponding upload field in the backend, which I think might be a good compromise: the backend stays usable, the error is still visible and it is obviuos for editors, where the error occured.

Edit: Patch applies with some offset but fully functional to 4.2.8 as well + added file for 4.1.12.


Updated by Steffen Kamper over 12 years ago

Ralf, you only check for missing file. If there is another problem, you'll get the old situation.
Why not check file with is_readable?


Updated by Ralf Hettinger over 12 years ago

Steffen, point taken.

So what would you think about the following?
if (!(file_exists($theFile_abs) && is_readable($theFile_abs))) {

To be even more complete, there should be a check on is_writable as well, since if the file isn't writable, that would be no proper situation as well imo. Maybe a warning should be outputted in this case?


Updated by Steffen Kamper over 12 years ago

Ralf, file_exists is not needed.
Returns TRUE if the file or directory specified by filename exists and is readable, FALSE otherwise.

I don't see need for is_writable in this context, file is only used by reading.


Updated by Ralf Hettinger over 12 years ago

You're right - using is_readable should be fine. I thought to remember that there was some PHP bug... but I couldn't find it - so it's probably just not there :)

I was thinking about is_writeable for outputting a warning - but agreed; this certainly is the wrong scope since it's just about generating thumbs here.


Updated by Alexander Opitz over 8 years ago

  • Status changed from Accepted to Needs Feedback
  • Target version deleted (0)
  • TYPO3 Version set to 4.1

The issue is very old, does this issue exists in newer versions of TYPO3 CMS (4.5 or 6.1)?


Updated by Alexander Opitz over 8 years ago

  • Status changed from Needs Feedback to Closed
  • Assignee deleted (Rupert Germann)

No feedback for over 90 days.


Updated by Michael Pfenning almost 8 years ago

This bug still exists. TYPO3 CMS 4.7, TV 1.8.0

Also available in: Atom PDF