BugFix - Stop Re-Upload Same File Due To File Extension

[alperozturk96]

• Tests written, or not not needed

Issue

When uploading a file, the app changes the file extension to lowercase (e.g., .JPG becomes .jpg). This leads to duplicate uploads if the same file was previously uploaded with the original (uppercase) extension, since the system may treat .JPG and .jpg as different files.

This behavior has resulted in thousands of unintended duplicates.

How to reproduce?

1. Have a file in folder, e.g. File.JPG
2. Try to upload exact same file but with lowercased extension e.g. File.jpg

be.mov

Solution

If one of the remote path variant (File.JPG or File.jpg) exists in remote and file didn't change, skip the upload process.

@mpivchev Please check this for iOS as well. @tobiasKaminsky fyi.

After

pt.mp4

How to test?

1. Files with the exact same name, content and only differing in upper- or lowercase extensions should not be re-uploaded.
2. If a file has the same name but different content, a conflict resolution dialog must be shown.

[alperozturk96]

/backport to stable-3.32

[alperozturk96]

OfflineOperationWorker was updated to use the logic in FileUtil to prevent code duplication and unify similar functionality.

[alperozturk96]

@tobiasKaminsky @ZetaTom

I need to compare a local file intended for upload with an existing remote file to determine if they are exactly the same. While file size can be used as a basic check, I’m looking for a more reliable method.

Using eTags is not feasible in this case, as the file to be uploaded (OCUpload) does not have an eTag yet. Similarly, relying on the modification timestamp is unreliable, since it can change due to non-content-related operations such as permission updates or file copying.

At this point, I have a java.io.File object and an OCFile instance, and I need to determine whether they represent the same file content.

Any suggestions for a more robust comparison method beyond file size?

[github-actions]

test-Unit test failed, but no output was generated. Maybe a preliminary stage failed.

[github-actions]

Codacy

Lint

Type	master	PR
Warnings	48	48
Errors	11	11

SpotBugs

Category	Base	New
Bad practice	60	60
Correctness	63	63
Dodgy code	296	296
Experimental	1	1
Internationalization	7	7
Malicious code vulnerability	2	2
Multithreaded correctness	35	35
Performance	50	50
Security	18	18
Total	532	532

[github-actions]

APK file: https://www.kaminsky.me/nc-dev/android-artifacts/15253.apk



To test this change/fix you can simply download above APK file and install and test it in parallel to your existing Nextcloud app.

[fabolhak]

Unfortunately, this change makes it worse for my use case 😢. I use to following workflow to upload my pictures (with ending .JPG):

• open the inbuilt Files app
• select all images I want to store on my nextcloud instance
• move all files to the specific folder using the Nextcloud storage provider in files app

With the previous version two files were created:

• empty .JPG file
• actual .jpg file

For some reason the .JPG files were never deleted and I had to clean them up manually.

With the linked version above, I only get the following file:

• empty .JPG file

And the file with actual content is lost :(

So please consider reworking the whole "changing of file extension to lowercase feature" as it can cause a lot of trouble.

logs.txt

[tobiasKaminsky]

• auto rename should only be working when "enforce windows compatible mode" is enabled, which is not clear by server right now (server justs adds some additional config to capabilities)
• if auto-rename is enabled, then our app should check before upload, if a renamed file exists and if yes, it should show the conflict resolution screen

[fabolhak]

I have "enforce windows compatible mode" disabled. Still the file extensions get renamed from upper case to lower case: JPG -> jpg or MP4 -> mp4

Uploading via the Nextcloud app works fine (still does the renaming), but uploading via the inbuilt File browser is broken.