make sure mtime is always an int

[individual-it]

Description

HTTP_X_OC_MTIME is cast to float, then checked if its outside the int range if yes it set to the max values and if not the original value is cast to int
That should make sure afterwards we have an int value that is in PHP range, in any PHP version
This is an alternative approach to #27615 , don't throw any errors but simply make sure the value is legal.

This fix partly fixes #23228. On a system that uses 32bit integer it would protect the database to receive a value that is too big, but on a 64bit system the value would still be given to the database.

Related Issue

#27960
#23228

Motivation and Context

currently mtime can only be stored as int, but the server accepts also other types.

How Has This Been Tested?

run new tests against pgsql, mysql & sqlite on PHP 7.1

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[butonic]

the tests all fail with:

OCA\DAV\Tests\unit\Connector\Sabre\FileTest::testPutSingleFileLegalMtime with data set "string starting with number following by char" ('2345asdf', 2345)
PHPUnit_Framework_Exception: PHP Fatal error:  Uncaught Error: Call to a member function getMailHeaderColor() on null in /var/lib/jenkins/workspace/owncloud-core_core_PR-28066-B7BY7XW3TLFFWQC2SWMA4Z6JVKZQNISNGYFNFF4TAEYZY3ESC5IA/core/templates/mail.php:5
Stack trace:
#0 -(1928): require_once()
#1 {main}
  thrown in /var/lib/jenkins/workspace/owncloud-core_core_PR-28066-B7BY7XW3TLFFWQC2SWMA4Z6JVKZQNISNGYFNFF4TAEYZY3ESC5IA/core/templates/mail.php on line 5

[phil-davis]

This looks good. The only problem is what happened to the tests with the weird mail error thing.
So approving here, with the proviso that of course the tests have to be made to pass somehow.

[individual-it]

added changes as requested
looks like @preserveGlobalState disabled fixed the tests

[individual-it]

some tests on Primary Objectstore: swift are failing when negative mtime. Maybe swift does not support negative mtime

[phil-davis]

I wonder what the requirement is to be able to store files from before 1970?
Is there a way to know the "capabilities" of a back-end storage and e.g. if it cannot accept negative mtime then set any negative mtime to zero.

[individual-it]

I think Swift does not accept any timestamps < 0
https://git.openstack.org/cgit/openstack/swift/commit/?id=e6194113a3c81563590eabf8f761ccb988bb917c

[individual-it]

all test passing now.
please re-review

[phil-davis]

Note: Travis litmus-v1 job fails because of:
wget: unable to resolve host address `www.webdav.org'

anything that triggers real work in that job is failing.
See #28103 for a fix.

I guess other PRs that have changes that trigger the litmus-v1 job will also have this problem.

[phil-davis]

Apologies to @individual-it - I was thinking about how the negative mtime support checks could be refactor a bit and to make it easy in future to add any other conditionals for when negative mtime [is|is not] supported. I accidentally pushed straight to this branch, when I intended to check/test the changes myself. Anyway, the tests have run here and hopefully somebody will think my edits are reasonable.
This is once again ready for review.

[individual-it]

@phil-davis I like your changes 👍

[butonic]

Well, I'd like to use the OCP api for getting file information, but since the DAV app still isn't using it I guess we can omit it for now...

[butonic]

Looking at the console output of Jenkins the integration tests seem to pass, but why doeas the overview at https://jenkins.owncloud.org/job/owncloud-core/job/core/job/PR-28066/ say it was "paused for 0ms"?

[butonic]

Maybe a UI glitch? https://jenkins.owncloud.org/job/owncloud-core/job/core/job/PR-28066/18/flowGraphTable/ looks fine

[phil-davis]

I did try to stop the job for "Refactor negative mtime support checking" commit yesterday when I realized that I had pushed to @individual-it 's branch, and that I still had a syntax error. I never worked out how I could stop the job, but I had clicked the pause button. I didn't touch anything in Jenkins for that last run where @individual-it had rebased and trigger the build/tests again. Hmmm...

[individual-it]

it had a strange error after rebase https://jenkins.owncloud.org/job/owncloud-core/job/core/job/PR-28066/17/ and I could not work out why that was happening that's why I tried to restart it. And now it came up green. If you look at the detailed log it did run the integration tests https://jenkins.owncloud.org/job/owncloud-core/job/core/job/PR-28066/18/consoleText
Only it does not display it in the overview. So I think @butonic is correct in saying that its only a display error and we can merge this PR

[PVince81]

please backport to stable10 where the bug first appeared

[phil-davis]

Backport to stable10 #28186

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.