In some cases, at least when importing images from a mobile device via
Drive Mobile's synchronization, we can have files with a creation date
(created_at field) that is more recent than the latest modification
date (updated_at field).
This should be impossible since cozy-stack forbids these situations
but we do see them in production.
As a consequence, further metadata updates on the file, such as a
move, will be rejected by cozy-stack due to the "invalid
modification date".
Since the user cannot fix this problem easily, we don't want to stop
the Desktop synchronization when we encounter such files.
This is why we'll use for the updated_at field value, in every
request sent to cozy-stack, the most recent date between the
following:
the local last modification date
the remote last modification date
the remote creation date
Please make sure the following boxes are checked:
[x] PR is not too big
[x] it improves UX & DX in some way
[x] it includes unit tests matching the implementation changes
[ ] it includes scenarios matching a new behaviour or has been manually tested
In some cases, at least when importing images from a mobile device via Drive Mobile's synchronization, we can have files with a creation date (
created_atfield) that is more recent than the latest modification date (updated_atfield).This should be impossible since
cozy-stackforbids these situations but we do see them in production. As a consequence, further metadata updates on the file, such as a move, will be rejected bycozy-stackdue to the "invalid modification date".Since the user cannot fix this problem easily, we don't want to stop the Desktop synchronization when we encounter such files. This is why we'll use for the
updated_atfield value, in every request sent tocozy-stack, the most recent date between the following:Please make sure the following boxes are checked: