Reset last sync date of files written via DocumentsProvider#6751
Conversation
4fdd0d0 to
f23010c
Compare
While reviewing this I tried to find where we use precision of seconds, as we then should change this, but I cannot find it? |
Sorry for not explaining this better. The precision used is actually not obvious and I only found out about it with a long debugging session pinning down the bug that was probably introduced because millsecond precision is assumed as the java docs talk about the time being in milliseconds. Eventually I noticed that the last three digits of the Here's a related SO question: https://stackoverflow.com/questions/24804618/get-file-mtime-with-millisecond-resolution-from-java Note that this PR is superfluous once #6753 is implemented. However, since we don't know when this will land, it might make sense to merge this one already since it fixes a rather serious data-loss bug. |
|
Thanks for your detailed explanation! Then let us get this in 👍 |
The sync operation detects changes by comparing timestamps in milliseconds. However, the local modification time only has a precision of seconds (even though given in milliseconds). When the DocumentsProvider is used programmatically, operations such as a create and a subsequent write can happen within the same second causing the sync operation to not detect the change and therefore failing to upload a file causing data loss. This commit also moves the file close listener to the thread used by the DocumentsStorageProvider as this is more appropriate than the UI thread. Fixes nextcloud#6726 Signed-off-by: Torsten Grote <t@grobox.de>
f23010c to
64ec705
Compare
|
APK file: https://www.kaminsky.me/nc-dev/android-artifacts/15527.apk |
Codacy405Lint
SpotBugs (new)
SpotBugs (master)
|
Codecov Report
@@ Coverage Diff @@
## master #6751 +/- ##
============================================
+ Coverage 27.81% 27.88% +0.07%
Complexity 5 5
============================================
Files 427 427
Lines 34237 34239 +2
Branches 4735 4735
============================================
+ Hits 9522 9549 +27
+ Misses 23297 23260 -37
- Partials 1418 1430 +12
|

The sync operation detects changes by comparing timestamps in milliseconds. However, the local modification time only has a precision of seconds (even though given in milliseconds).
When the DocumentsProvider is used programmatically, operations such as a create and a subsequent write can happen within the same second causing the sync operation to not detect the change and therefore failing to upload a file causing data loss.
This MR also moves the file close listener to the thread used by the DocumentsStorageProvider as this is more appropriate than the UI thread.
Fixes #6726 (I can create other tickets about the side-issues identified there)