Add mtime and storage_mtime to db:convert-filecache-bigint

[agates]

Adding some columns that were left out of the bigint conversion for the filecache.

See #7637

[rullzer]

I guess this makes sense as a temp solution yes.

[nickvergessen]

But really a temp solution. Two things I don't like about this:

1. There should be no MTime yet which is 2038 (because that means the file is to be edited in 20+years, no one can know now. Should really find out why this happens sometimes.
2. The column should be migrated to datetime one day 🙊

[agates]

@nickvergessen The only thing I can think of (and I don't have evidence of it right now, as it only happened once or twice) is when I uploaded a PDF from the Android client.

Looking through my files right now, I actually see several that were modified "in 20 years", all of which precisely show "January 18, 2038 9:14 PM". Many of them have existed since I created my server, so I know I haven't touched them myself recently.

Unfortunately I don't have any steps to reproduce it, but I had to make this change to be able to get Nextcloud working again for me :/. Obviously it's a much larger issue for places where modification time is important -- I just run it for myself.

But the storage type seems to be just symptom of another issue.

[ryhaberecht]

@agates I initially stumbled upon the issue after trying to upload a PDF from my Linux client. The PDF came straight from my bank (web download) and my local file system also stated an mtime from 2038. It never happened again, though.
This special date in 2038 is nothing more than a full 32 bit array of all 1's interpreted as UNIX epoch timestamp. But I have no idea where this originated from. So no idea where to start debugging :-/

[MorrisJobke]

@nickvergessen @rullzer Should we backport this to stable13?

[MorrisJobke]

@nickvergessen @rullzer Should we backport this to stable13?

Ping

[rullzer]

I have no prefrence here...

[nickvergessen]

me neither, mtime dates from 2038+ are invalid in my point of view and just burrow other problems.

[rullzer]

So the lets keep it at no for now...

[tflidd]

What's the recommendation for users facing this issue?
https://help.nextcloud.com/t/migration-from-owncloud-10-0-7-to-nextcloud-12-06-failed/29533

[ryhaberecht]

On the client you are uploading from: search for files with a modified-timestamp of >= 2038, change the timestamp to a sane value.
On Unixoids a pipe of find and touch should do the trick. Maybe someone can put together the necessary parameters and put them in the migration documentation?