Dubious overwrite logic with etag / server side conflict handling

[PVince81]

See these:

apps/files/src/mixins.js|207 col 61| this.$_ocUpload(file, item.fullPath, exists.etag)
apps/files/src/mixins.js|237 col 59| this.$_ocUpload(files[i], files[i].name, exists.etag)

it seems to be passing in an etag but the method $_ocUpload takes an overwrite boolean as parameter.

It is likely that folder upload is not properly processing overwrites, unless it just works "by chance".

@LukasHirt FYI

[PVince81]

Compared to OC 10, it also seems that the logic is not relying on the 412 or 409 error codes on upload to trigger the overwrite dialog.

I'll tag this as bug now, we need to revise the way how we detect conflicts and manage concurrency.

Here's an example case that is not handled properly:

1. Create a folder "conflict"
2. Open the folder
3. Open another browser tab and navigate into the folder "conflict" there as well
4. In the first browser tab, upload a file "test.txt"
5. In the second browser tab, upload the same file "test.txt"

Expected result

Conflict dialog "do you want to overwrite ?", then confirming would attempt the upload again.

Actual result

[tbsbdr]

needs to be checked with uptodate ocis and oc10 backends.

[JammingBen]

Current behavior for both backend is that the second tab will overwrite the uploaded file without showing any kind of conflict dialog. I guess the expected behavior is that this dialog shows though, right @kulmann @tbsbdr ?

[tbsbdr]

👍 correct

[tbsbdr]

current behaviour is:

• upload is successful now (does not show an error message in the ui any more)
• creates a new version (in oc10 and ocis)
• showing a conflict-resolve dialog would be to expensive for folders with ex. 10k files inside --> makes Fetch resources before uploading or creating resources #7664 obsolete right @kulmann ?

closing as current behaviour is good enough - avoids dataloss 👍