TYPO3 Core

Same happens with typo3 4.1.12 on PHP4.4.8 on FreeBSD.

That is with all directories writable: green checks

I noted that the freetype test has no picture, the picturetag has a src="/typo3/install/index.php?TYPO3_INSTALL[type]=config&testingTrueTypeSupport=1" but nothing is shown. I hope this is a hint.

Thanks Jacco; group write 664 did the trick

Same on TYPO3 4.2.8.

$enableInstallToolFile = PATH_typo3conf . 'ENABLE_INSTALL_TOOL';
            if (is_file ($enableInstallToolFile)) {
                    // Extend the age of the ENABLE_INSTALL_TOOL file by one hour
                touch ($enableInstallToolFile);
            }

I think the EnableInstalltool file needs chmod rights, when I put it on 777, the error was gone ;-)

4.2.8:

Warning: touch() [function.touch]: Utime failed: Permission denied in /home/mydomain/public_html/typo3_src-4.2.8/typo3/sysext/install/mod/class.tx_install.php on line 319

Maybe you created the file with wrong permission- with a shell "touch" the first time?

Could you please remove the file (manually), and recreate it within the user->setup option, and see if the error still occurs?

No shell used, I created it years ago on my windows workstation in the file system, then I uploaded it using FTP. I copied this file numerous times to new typo3 installs. Always worked until recent versions (4.1 branch). Now i do a 664 using filezilla and it works. No big deal, but it would be very helpful if the "The Installtool is locked etc." notice told you immediately because the "Utime failed etc" warning is not really a pointer...

user->setup or the user admin offer no way to create this file. I'm not aware of a possibility to create this file within the backend (and I think there should not be a possibility) but if there is I would like to know where to find it!

Thanks for addressing this issue!

You just have to make sure the file is writable.
This is due to the fact that in latest TYPO3 versions the file will be removed if it is too "old". To avoid the file being removed before you finished your installation, the install tool uses touch() and therefor you have to make sure that the file is writable for the user TYPO3 is running at.

Creating the file on a Debian system while being "root" will give the same result, which can be fixed by a simple chown www-data:www-data

So IMHO this is not a TYPO3 bug but a user generated problem.

IMHO this is a bug because the user is not made aware of this requirement

So the following text should do the job:

The Install Tool is locked.

Fix: Create a file typo3conf/ENABLE_INSTALL_TOOL
This file may simply be empty.
Be sure it uses the same user and group your webserver is running at. 

For security reasons, it is highly recommended to rename or delete the file after the operation is finished.

If the file has not been touched within the last hour TYPO3 has automatically deleted it, so it needs to be created again.

Patch attached.

Great!, hmm, I think the notice can be made more generic:

- "Be sure it uses etc." --> "Make sure it is writable by the same user and group your webserver is running at"

- "If the file has not been touched etc" --> "If the installtool has not been used within the last hour TYPO3 wil automatically delete it. So, if you need the installtool after a one hour period you will need to create the file again."

@Jo Hasenau: This is no practicable solution. Only admin user have the possibility to create a file with the user and group of the webserver. Only few persons have their own root server for TYPO3.
At least a PHP script should be provided which is able to create the file typo3conf/ENABLE_INSTALL_TOOL . The PHP script could be renamed to make it not executable afterwards.

The first one implies that you could use chmod 777 also, which might be working but is never a good idea. It should belong to the same user and group instead.

The last one is simply not true, since the install has ot been used at all i.e. if you use it for the first time. The install tool is checking if the file has been changed within the last hour, so the wording in the patch is correct and understandable.

@Franz Koch: It's just vice versa: Your approach is the non practicable solution, because "TYPO3 backend admin" is not the same as "TYPO3 superadmin" and there are many situations where the backend admin should not be able to enter the install tool at all.

If you are running your TYPO3 in a shared hosting, it's up to the hoster to provide a script in the administration interface that can create the file when necessary.

If you got non root shell access the user and groupd should be correct anyway.

@Jo: AFAIK there is no superadmin available in TYPO3.

It should be possible to turn the automatical removal of the typo3conf/ENABLE_INSTALL_TOOL.
Why isn't it sufficient if the file is just there? It should be possible to allow also a lower security level than the paranoid one.

@Franz Koch: You are right with your last one, but this has nothing to do with the access rights for the file, does it?

If you want to change this behaviour this should be another bug, filed as 'feature request'.

it's possible to switch off the deletion of ENABLE_INSTALL_TOOL.
Just edit it and insert following text: KEEP_FILE

What about adding an @ to the touch() call?
This would omit the PHP warning (or does this cause a locked install tool without giving a clear reason to the user?)

My patch adds a check for is_writable() before touching the file.

v2 is now pending in core list.

The hints of a locked install tool have to be optimized, I agree. But that's another RFC.

Your patch fixes the error, thanks! That leaves the documentation error unsolved I am not into the procedures of the bugsystem After the patch is submitted, can we change the category of this bug to something like "Documentation Request"? Or should a separate request be filed?

Attached v3, which fixes a bug and has an improvement (see core-list discussions). Previous patch didn't really work, sorry.

This bug's topic is the PHP warning and not improvement of the hints of the install tool. So here has nothing to be changed (indeed the whole discussion is IMHO off-topic ;)

Please create a new bug report with the corresponding topic (and patch :) ). I also planned to do this after beta release, but feel free to start right now :)

I'd ask you to note the new bug number here and point from the new one to the discussions in this report (maybe you could summarize them in one sentence).

Thanks!

• Trunk (rev. 6062)
• TYPO3_4-2 (rev. 6063)
• TYPO3_4-1 (rev. 6064)