fix(FileCache): mtime when not provided backend at zero

[ze42]

• Resolves: # (no related issue found)

Summary

Some external backend always send 0 as modTime.

Creating a file without explicit timestamp coming from client (as in just creating it now, without having a modTime coming along the data), the file will be created in the backend, and nextcloud will read the modTime from the backend and store it as created in 1970...

More details here

TODO

• ...

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)

[kesselb]

Some external backend always send 0 as modTime.

Please elaborate.

[ze42]

Some external backend always send 0 as modTime.

Please elaborate.

I came accross an external storage backend not able to handle modtime, and always reporting mtime = 0.

When dumping a file that has a modtime, the modtime is stored in NextCloud, though the backend storage has zero.

When creating a file/directory without having a modtime coming along, the modtime is currently set to 0 (so, Jan 1st 1970), instead of having something like "now" used.

[kesselb]

What storage backend / service is that, and how is it connected with Nextcloud?

I'm unsure if 0 = now is a sane default.
If there's known quirks with a storage backend, we usually try to fix it within the concrete implementation.

[ze42]

What storage backend / service is that, and how is it connected with Nextcloud?

I'm unsure if 0 = now is a sane default. If there's known quirks with a storage backend, we usually try to fix it within the concrete implementation.

We are trying to develop a backend using webdav and storing into IPFS.

IPFS is currently not able to store any date.

So, we have it as external storage on nextcloud, but without this patch, any files created there gets the date from 1970.

Would you have any alternative suggestion? Maybe a way to implement/configure per (external) storage a do-not-trust-dates?

[kesselb]

So, we have it as external storage on nextcloud, but without this patch, any files created there gets the date from 1970.

Because your backend sends 1970 as modified date ;)

Would you have any alternative suggestion?

If your backend does not provide getlastmodified, why do you send it with 0 as value?

Our code should already handle responses without getlastmodified¹ properly.

Footnotes

1. https://github.com/nextcloud/server/blob/d87c23242b96903d59b978a936179f5441c26773/lib/private/Files/Storage/DAV.php#L606 ↩

[github-actions]

Hello there,
Thank you so much for taking the time and effort to create a pull request to our Nextcloud project.

We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process.

Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6

Thank you for contributing to Nextcloud and we hope to hear from you soon!

[kesselb]

Hi @ze42, is this resolved?