Deleting multiple files with the same name but different origin close together in time results in only one file in the trashbin

[jasson99]

Describe the bug

When multiple files with the same name but different original location are deleted such that the time gap between their deletion is negligible, only the last deleted file is present in the trashbin.

Steps to reproduce

Steps to reproduce the behavior:

1. Create folders folderA , folderB, folderC, and folderD.
2. Create file textfile0.txt
3. Copy file textfile0.txt to all the folders created in step 1.
4. Delete the following resources: textfile0.txt, folderA/textfile0.txt, folderB/textfile0.txt, folderC/textfile0.txt, and folderD/textfile0.txt

curl -k -u admin:admin -X DELETE https://localhost:9200/remote.php/webdav/textfile0.txt -v; 
curl -k -u admin:admin -X DELETE https://localhost:9200/remote.php/webdav/folderA/textfile0.txt -v; 
curl -k -u admin:admin -X DELETE https://localhost:9200/remote.php/webdav/folderB/textfile0.txt -v; 
curl -k -u admin:admin -X DELETE https://localhost:9200/remote.php/webdav/folderC/textfile0.txt -v; 
curl -k -u admin:admin -X DELETE https://localhost:9200/remote.php/webdav/folderD/textfile0.txt -v;


> DELETE /remote.php/webdav/textfile0.txt HTTP/1.1
< HTTP/1.1 204 No Content

> DELETE /remote.php/webdav/folderA/textfile0.txt HTTP/1.1
< HTTP/1.1 204 No Content

> DELETE /remote.php/webdav/folderB/textfile0.txt HTTP/1.1
< HTTP/1.1 204 No Content

> DELETE /remote.php/webdav/folderC/textfile0.txt HTTP/1.1
< HTTP/1.1 204 No Content

> DELETE /remote.php/webdav/folderD/textfile0.txt HTTP/1.1
< HTTP/1.1 204 No Content

Expected behavior

All the deleted resources should exist in the trashbin.

Actual behavior

Only the file folderD/textfile0.txt is present in the trashbin.

Setup

Please describe how you started the server and provide a list of relevant environment variables.

STORAGE_USERS_DRIVER=owncloud
STORAGE_HOME_DRIVER=owncloud

Additional context

Add any other context about the problem here.

[C0rby]

This has been fixed here: cs3org/reva#1833
But this specific steps could still fail with the fix. See cs3org/reva#1833 (comment)

[phil-davis]

Note: In the core API tests we have a function pauseUploadDelete() because the oC10 implementation already has this kind of known issue - oC10 trashbin and versions use Unix timestamps (seconds) in their back-end implementation. So the core API test scenarios already put a 1-second sleep between each delete or upload action. That avoids the "known feature" of oC10.

We could adjust the core API test code so that the sleep is not done if "running on OCIS or reva". And that would help confirm if OCIS behaves better.

I added this to the QA Test Automation project so that we think about doing this...

[dpakach]

@phil-davis I tested removing the wait function between uploads and deletes.
https://drone.owncloud.com/owncloud/ocis/5690/37/7
It passes on ocis running with ocis storage driver but fails on ocis with owncloud storage driver. I think that was as expected. should we add an extra env var for the storage driver and only wait for owncloud driver, or consider the owncloud storage driver behavior a bug or consider both ok as the oc10 tests behave the same way and since it is the standard for all oc implementations and we can consider the behavior in ocis storage driver just a better improvement over the standard.

[phil-davis]

The test for this is likely to have intermittent passes on owncloud storage - if the test happens to run slow enough.

Let's add a test scenario in oC10 core that does lots of deletes quickly... And add a way to control the test sleeping behavior in pauseUploadDelete(). IMO pauseUploadDelete() should do nothing by default, and do the waiting if some env variable is set. The env var could even specify the number of seconds to wait.

Then we can control this in each CI - in oC10 we can define the env var to 1. With owncloud storage driver we can define the env var. With other storage drivers, we can let the tests run as fast as possible.

[ScharfViktor]

re-tested with local server oCIS version 1.11.0
behavior is same as expected result. I suggest to close

[phil-davis]

We implemented owncloud/core#38929 and CI knows to wait 1 second between multiple uploads, deletes etc. in the appropriate test pipelines. We know that this "1-second rule" is an accepted feature/limitation of oC10 and some oCIS storage drivers.