Automatic uploads: `Original file will be removed from original folder` should delete original file if it exists

[bilogic]

1. Before setting up Automatic picture uploads, my android DCIM's folder has 3 files, 1 image and 2 videos
2. After pointing to a remote folder and choosing Original file will be removed from original folder, the 1 image refuses to budge
3. It continues to stay on device because a copy already exists on my server
4. If I delete the server's copy, then it gets moved from the device to the server shortly

Problem: user is left wondering why certain images are not (re)moved from the device

Possible solution(s):

1. Report in Uploads tab that files could not be uploaded because they already exists on server, currently nothing reported for this case)
2. If the hashes of remote and local file are the same, then just delete local file and considered it uploaded
3. If hashes are different, upload as a different name?

[guruz]

I like the hash solution, sounds nice. (2+3)

We have pending PRs for those automatic uploads, need to find the time to merge those before fixing this here (maybe it's fixed already?)... #129 #56
CC @PhilippThaler

[junkerderprovinz]

Thanks for the clear write-up. I went through the current code and I think there are two separate things here, and it would help to know which one you are seeing.

The part that matches your symptom. RemoveSourceFileWorker throws away the result of the delete:

opencloudApp/src/main/java/eu/opencloud/android/workers/RemoveSourceFileWorker.kt:43-53

val documentFile = DocumentFile.fromSingleUri(appContext, contentUri)
documentFile?.delete()
Result.success()

DocumentFile.delete() returns a Boolean. If the provider refuses, the worker still reports success and nothing surfaces anywhere. Combined with the skip in AutomaticUploadsWorker.kt:151 (existsNonFailedTransferForUri), the transfer counts as done, the file stays on the device, and it is never reconsidered. That is a good match for "refuses to budge" plus your point (1), nothing reported in the Uploads tab.

The part that your hash idea in (2)/(3) fixes, but which should behave differently. checkNameCollisionAndGetAnAvailableOneInCase() (workers/UploadFileFromContentUriWorker.kt:359-371) calls RemoteFileUtils.getAvailableRemotePath() (utils/RemoteFileUtils.kt:36-84), which appends " (1)", " (2)" with no content comparison. If that path were firing for your image, you would end up with a second copy on the server under a (1) name and the local original would be removed. Since you are seeing the original stay put, I suspect that is not what happened to you, but it is worth confirming.

So, two questions: does a file like IMG_xxxx (1).jpg show up in the remote folder for that image, and what does the Uploads tab show for it, nothing at all or a completed entry?

One more thing I noticed while reading, relevant to (2)/(3) whichever way this goes. existsFile() (utils/RemoteFileUtils.kt:86-99) returns execute(client).isSuccess, and CheckPathExistenceRemoteOperation.kt:74-80 returns a non-OK result both for a genuine 404 and for any thrown exception. A dropped connection or an expired token during the collision check is therefore read as "the file is not there", the rename is skipped, and the upload PUTs straight over the existing remote file (requiredEtag = null, UploadFileFromContentUriWorker.kt:455-464). With MOVE the local original is then deleted. Worth separating "does not exist" from "could not check" as part of the hash work.

Happy to send a small PR for the swallowed delete result on its own, it is a handful of lines in RemoveSourceFileWorker plus a transfer-status update, and it does not touch anything #129 or #56 move around. Would you rather have that now, or after those two land?

Assisted-by: Claude Code:claude-opus-5

[bilogic]

does a file like IMG_xxxx (1).jpg show up in the remote folder for that image, and what does the Uploads tab show for it, nothing at all or a completed entry?

Sorry, I'm not sure what you are asking. If you meant 3 where we rename, renaming is up to you to set a convention.. and logically one would report that filename A1 was uploaded as filename A2 due to filenames clash. Please use human words, AI makes the question unnecessarily complicated.

2nd question, yes you should not be swallowing errors or non compliance to the command to auto upload.