Project

General

Profile

Actions

Bug #37425

closed

Install Tool renames all tables and fields to "zzz_deleted_"

Added by Stephan Großberndt over 12 years ago. Updated almost 10 years ago.

Status:
Closed
Priority:
Must have
Assignee:
-
Category:
Install Tool
Target version:
-
Start date:
2012-05-23
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
4.5
PHP Version:
5.2
Tags:
Complexity:
easy
Is Regression:
No
Sprint Focus:

Description

Since 4.5.16 the install tool renames all tables and field that should be deleted to "zzz_deleted_" and does not append the former name.


Files

zzz_deleted.png (20.2 KB) zzz_deleted.png Stephan Großberndt, 2012-05-23 11:13

Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Bug #33580: prepending "zzz_deleted_" might exceed the maximal lenght for column namesClosedTolleiv Nietsch2012-02-01

Actions
Actions #1

Updated by Jochen Weiland over 12 years ago

I could not duplicate this with 4.5.16, could you please give some more information about your environment (OS, PHP version).

Actions #2

Updated by Markus Klein over 12 years ago

I'm not sure if this is really related to #33580.
Looking at the code, the result you described could only occur, if substr($table, ...) would return an empty string.
But according to the PHP documentation this can never happen. Any error would return FALSE and that would be visible in the output.

Actions #3

Updated by Jigal van Hemert over 12 years ago

  • Status changed from New to Needs Feedback

Can you provide the requested information?

Actions #4

Updated by Stephan Großberndt over 12 years ago

The problem is the substr() function of PHP:

Using PHP 5.3 the code

var_dump(substr('test', -4));
var_dump(substr('test', -5));
returns
string(4) "test" 
string(4) "test"
while using PHP 5.2 it returns
string(4) "test" 
bool(false)

The PHP documentation [http://php.net/manual/en/function.substr.php] states for the start parameter

If string is less than or equal to start characters long, FALSE will be returned. 
nevertheless PHP 5.3 (incorrectly but conveniently) returns the complete string.

In the Install Tool the start parameter for substr() is calculated by

$deletedPrefixLength - self::MYSQL_MAXIMUM_FIELD_WIDTH
which is -52, so with PHP 5.2 the delete string becomes "zzz_deleted".FALSE

PHP 5.2 is officially supported for 4.5 and the problem was not there until 4.5.16, so this must be fixed (and should also be taken into account if used similarly somewhere else).

Actions #5

Updated by Markus Klein over 12 years ago

Yes that's exactly what I was referring to, but I still have no clue, why your screenshot doesn't show the FALSE in the output of the Installer.
I'll provide a patch, once we're able to explain why this FALSE is not shown.

Actions #6

Updated by Stephan Großberndt over 12 years ago

A string concatenation of a string with boolean FALSE results only in the string: "zzz_deleted_".FALSE == "zzz_deleted_". To be compatible with PHP 5.2 the start parameter of substr() must not be smaller than -(strlen($table)) - something like

substr($table, max($deletedPrefixLength - self::MYSQL_MAXIMUM_FIELD_WIDTH, strlen($table) * -1 ))
should do the trick.

Actions #7

Updated by Jigal van Hemert over 12 years ago

  • Status changed from Needs Feedback to Accepted

The problem is not that "string is less than or equal to start characters wrong": The string 'test' is 4 characters long, which is larger than any negative number.

The problem is probably with the line in the changelog in the PHP documentation:

5.2.2 - 5.2.6     If the start parameter indicates the position of a negative truncation or beyond, false is returned. Other versions get the string from start.

Your PHP 5.2 installation is probably one of these versions. Later versions (including PHP 5.3, 5.4, etc.) will return the entire string.

The easiest solution is IMO to only use substr() if it actually would remove part of the string.

Actions #8

Updated by Jigal van Hemert over 12 years ago

  • Target version set to 4.5.17
  • PHP Version set to 5.2
  • Complexity set to easy
Actions #9

Updated by Markus Klein over 11 years ago

  • Target version changed from 4.5.17 to next-patchlevel
Actions #10

Updated by Ernesto Baschny over 11 years ago

At least TYPO3 4.5 should be solved, as it's minimum required PHP version is 5.2.0.

TYPO3 4.7 and later require PHP 5.3, so it should be ok. Thanks for analysing this Jigal.

Actions #11

Updated by Mathias Schreiber almost 10 years ago

  • Target version changed from next-patchlevel to 7.4 (Backend)
Actions #12

Updated by Markus Klein almost 10 years ago

  • Status changed from Accepted to Needs Feedback
  • Target version deleted (7.4 (Backend))
  • Is Regression set to No

I'd opt to reject this one as 4.5 only gets priority fixes.

Actions #13

Updated by Stephan Großberndt almost 10 years ago

This bugfix would have made sense to fix two years ago. It's still bad since 5.2 is officially supported but for me its ok to reject it. We have several 4.5 installations but none of them on 5.2. Even debian squeeze (with lts still supported) has 5.3.3-7 on board, only with lenny (not supported since 2/2012) you have 5.2.

"Enterprise CMS"-wise it should still be fixed - priority or not - the backup function of tables is broken.

Actions #14

Updated by Jigal van Hemert almost 10 years ago

  • Status changed from Needs Feedback to Closed

It's only a problem in old PHP 5.2 versions. These have received security updates in the mean time and even the distros that kept the original PHP version numbers have included these bugfixes.
If there is an installation that still has this bug the installation has more and more severe (security) issues than this bug.

It's safe to close it for this reason.

If this decision is incorrect, please post a message in typo3.teams.bugs to re-open the issue.

Actions

Also available in: Atom PDF