Automatically qualify upload conflicts on file content (e.g. hash comparison)
- Dominant language
- Kotlin
- Stars
- 5.6k
- Forks
- 2k
- Avg merge
- 2d 18h
- Merged PRs (30d)
- 92
Description
### Is your feature request related to a problem? Please describe.
Often I want to make sure that a larger collection of files, that evolved over time on a mobile device, is completely available in its current state on nextcloud, before deleting it from the device's local storage. Earlier uploads consistently show up as synchronisation conflicts that need manual resolution each. This is a time consuming activity (much more so as the conflict resolution functionality shows some bugs, e.g. #8923).
### Describe the solution you'd like
I want that the nextcloud app checks itself for technical identity of the apparently conflicting files. As starting point, the filenames already are compared, now already qualified as conflict. Add to this comparison of the files' lengths and timestamps, creating a conflict if they differ. If these are all identical we have, from my pracitcal experience, an extremely high probability that the files actually are identical. As a final security line, compare the hash values of the files' contents, the remote file's hash computed on the server to avoid a download (I believe such an information is already available pre-computed on server-side, seeing the Duplicate Finder app in action?).
If the checks show that filenames, file lengths, date stamps, and content hashes do match, consider the file to be uploaded, do _not_ create a conflict dialogue, and proceed with the action that the user requested originally in the upload dialogue (i.e. delete or move the local file if that was requested).
### Describe alternatives you've considered
Content hash calculation could be done local in the app, but would require consideration when the remote file would need to be downloaded.
Smart integration with the existing functionality of the conflict resolution dialogue could be an option, e.g. do not compare the contents' hashes, but the previews that would be shown to the user: if everything you're showing to the user in the conflict resolution is identical, there's apparently no benefit of showing it and the app might as well consider the conflict resolved.
### Additional context
This suggested feature becomes very relevant with photo synchronisation on devices where the camera app generates filenames using sequential numbers rather than high resolution timestamps. Here, the auto-upload with deleting of original files cannot be used, as the camera re-starts the intendedly sequential numbers based on what files are left on local storage, generating absolutely confusing filename duplicates, and requires manual conflict resolution made worse by a preview bug reported in #8659 .
Contributor guide
Assessment
This issue has not been assessed yet.