Restore quietly ignores Backup SQL containing Windows linefeeds
briuri opened this issue · comments
This bug occurs on both the master branch and 3.0.x.x branch.
opencart/upload/admin/controller/tool/backup.php
(Master branch: Line 300, 3.0.x.x branch: Line 102)
- The Restore code looks for lines that end with a semicolon and Unix/Mac line feed (";\n") before sending the SQL queries to the DB adaptor.
- If the Restore code encounters Windows linefeeds (";\r\n"), queries are always skipped, but the process still ends with a misleading SUCCESS! message.
Normally, this isn't a problem because Backup (with OpenCart running on a Linux server) generates SQL with the correct linefeeds. However, there are plenty of chances for the linefeeds to accidentally get converted during Windows development. (In my case, simply moving the SQL files into an IntelliJ IDEA project converted from \n to \r\n until I realized what was going on and forced the IDE to keep the correct linefeed).
My local patch to handle either kind of line feed is below (based on 3.0.x.x branch) :
if ($start && substr($line, -2) == ";\n") {
$this->db->query(substr($sql, 0, strlen($sql) -2));
$start = false;
}
+ // Handle Windows line feeds, in case export SQL file was edited in Windows
+ if ($start && substr($line, -3) == ";\r\n") {
+ $this->db->query(substr($sql, 0, strlen($sql) -3));
+
+ $start = false;
+ }
Question: When you run the backup on a Windows machine, e.g. WAMP server (I don't have a Windows box on hand, so can't test it with Windows), not a Linux box, does it produce ";\n" or ";\r\n" line endings?
\r is included with Windows.
\ris included with Windows.
I know. But does the OpenCart backup generate the file with ";\r\n" or ";\n" line endings when run on e.g. a WAMP server?
\ris included with Windows.I know. But does the OpenCart backup generate the file with ";\r\n" or ";\n" line endings when run on e.g. a WAMP server?
This has been asked before. It has nothing to do whether it's used with WAMP server or not. The fact a platform is rather ran on a Windows virtual or Windows IIS environment, \r is still generated by default which is why it must be declared as for the same reason not to ignore the: might not be defined outputs from PHPStan since Windows will still require, either, variables or a carriage return.
Furthermore, more examples whereas \r is already used in the core:
- admin/controller/sale/order.php
- admin/view/template/sale/order_info.twig
- catalog/controller/account/address.php
- catalog/controller/account/order.php
- catalog/controller/account/subscription.php
- catalog/controller/mail/order.php
OK, thanks for the clarifications. Will amend 3.0.x.x accordingly for the backup/restore.
Now fixed for the 3.0.x.x branch: #13734
im running wamp and its fine.
could it be ur opening it in notepad? and not an IDE?
its php writing the code so windows shouldnt change anything.
its php writing the code so windows shouldnt change anything.
https://www.stackoverflow.com/questions/4824621/is-a-new-line-n-or-r-n
Windows vs. linux do have their differences with \r\n and \n.
the code is:
$output .= "\n";
and not \r\n
trhe file generated is not altered by windows! i dont give a fuck what hes using to open the file. its his file editor that is causing the screw up!~ maybe hes using microst word! either way there is no bug and no need foor u to state something that i have known possibly for longer than millennials have been alive!
the code is:
$output .= "\n";
and not \r\n
trhe file generated is not altered by windows! i dont give a fuck what hes using to open the file. its his file editor that is causing the screw up!~ maybe hes using microst word! either way there is no bug and no need foor u to state something that i have known possibly for longer than millennials have been alive!
Not talking about the $output . The first post addresses about the $start and $line. Whether you give a rat's ass or not, while it's already more than obvious that you don't already, anybody could begin before anyone else while they're at it but what those first starters seem to be missing is that two minutes of their time to make the comparison between different OSes when it comes to line changes, whether it's in or from an output file. By looking at the first posts and the previous replies, I don't see any mention with which tools this file was tested and even less the question that came with it.
Therefore, as a founder of the project, this should of been at least asked to the addresser. Instead, you automatically assumed that a paper clip or Microsoft tool were used rather than gathering the information from the user. Granted, it is not a bug as nowhere on my behalf where it was mentioned that it was. However, Windows does imply \r as opposed to other OSes to add new lines.
I stated in my original problem description that there is nothing wrong with Backup.
The part that OpenCart gets wrong is more of a misdemeanor than a felony: Restore happily tells you "You have successfully imported your database!" even when that is not true, which leads to unclear admin assumptions around data integrity and lost troubleshooting time. Having unexpected Windows linefeeds in the SQL file is a common probable cause, even if OpenCart isn't to blame for those linefeeds.
So, the most pedantic fix would be to update the Restore process with a factually correct message, like "This file has nothing to import!" or better "0 of 1000 lines imported." or even "You're a huge fool for ending up with Windows linefeeds in your data, how do you even make a living at software?!"
But it's even easier to help the poor admin out by making Restore accept Windows linefeeds, hence the patch I suggested.
its php writing the code so windows shouldnt change anything.
https://www.stackoverflow.com/questions/4824621/is-a-new-line-n-or-r-n
Funny to link to the whole story, but the most important comment is this here: https://stackoverflow.com/a/22623514/3450837
Reading this, PHP_EOL depends on which system is used (Windows or Linux) and should therefore not be used.
PHP also defines a newline character called PHP_EOL. This constant is set to the OS specific newline string for the machine PHP is running on (\r\n for Windows and \n for everything else).
I can fully understand (and agree with) Daniel to say f*** and see really no sense in changing the code (like @mhcwebdesign did).
While I do agree that the \r should not be used as an enforced requirement, why not just move this feature on the OC Marketplace altogether now that OCMod has been re-integrated and that OC v3.x releases still has this engine and that both series can still use the Event Triggers?
This would avoid all starters and all enders to keep bringing in the subject in the future and to help maintain the backup / restore compatibility on the OC Marketplace based on its compatibility aside from the rest of the core since the rest of the core does not encounter this issue anyways.
Sure, that also means that extension developers would use their own ways to import and export the data but that's what users are already encouraged to do on the OC Forum while using the OC v3.0.x.x versions and also what the extension/x in OC v4.x releases brings to the users.