[Nextcloud 28] New metadata background job can trigger error on 32-bit systems

[MichaIng]

[Nextcloud 28] New metadata background job can trigger error on 32-bit systems

[artonge]

I saw this error on every job execution because the job failed at the same point every time, right?

Good point. Here is a fix nextcloud/server#42198

[artonge]

Thanks for the report @MichaIng

1. It indeed looks like an invalid timestamp. I think we should wrap the line in a try/catch to handle timestamps incompatible with 32 bits. Would you have time to create a PR for that?
2. The metadata generation is expected to be done only once, as you said. We do have a background job to generate the metadata for existing files. It is expected to stop once all files have been handled. Maybe it is badly configured: https://github.com/nextcloud/server/blob/a0ff998/core/BackgroundJobs/GenerateMetadataJob.php

[artonge]

Reading the code again, I doubt that we can truly support 32 bit. Currently, the code expects an int, so any incompatible value will cause an issue. How do we handle incompatible mtime in our files code? @come-nc maybe?

[come-nc]

Reading the code again, I doubt that we can truly support 32 bit. Currently, the code expects an int, so any incompatible value will cause an issue. How do we handle incompatible mtime in our files code? @come-nc maybe?

You have to catch the error and log in this case, you cannot do much more if the timestamp does not fit in an int. But for original date this should not happen until 2038.

I am not sure we handle that correctly in all places, but incorrect mtimes are rare, usually mtime is set by Nextcloud itself.

For calendar, we officially do not support events past 2038 on 32bits.

[MichaIng]

It indeed looks like an invalid timestamp

It is 0000:00:00 00:00:00 on all affected files, or all tools fail to interpret it, including exiftool and show 0000:00:00 00:00:00 instead. If 2038 is too far after 1970, then year 0 indeed is a little too far before 😄.

The metadata generation is expected to be done only once, as you said.

I saw this error on every job execution because the job failed at the same point every time, right?