TYPO3 Core

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

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.

Configuration:
TYPO3 4.1.5
TV 1.3.3
DAM 1.0.11

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
@filemtime($theFile_abs)

and it works fine.

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

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.

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

System:
FreeBSD, Apache, MySQL
Typo3 4.2.1
no DAM
no TV

Can someone please help??

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

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?

hi
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.

@rupert
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 ...
"/[path]/typo3/uploads/tx_templavoila//[path]/typo3/fileadmin/media/yourpicture.jpg"

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

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.

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.

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?

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?

Ralf, file_exists is not needed.
is_readable:
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.

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.

This bug still exists. TYPO3 CMS 4.7, TV 1.8.0