Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Use single DELETE for a directory rather than many PROPFINDs & DELETEs #9798

Closed
cyberduck opened this issue Jan 6, 2017 · 3 comments
Closed

Use single DELETE for a directory rather than many PROPFINDs & DELETEs #9798

cyberduck opened this issue Jan 6, 2017 · 3 comments
Assignees
@dkocher
Labels
enhancement fixed webdav WebDAV Protocol Implementation
Milestone
5.4.1

Comments

@cyberduck
Copy link
Collaborator

e2e3c54 created the issue

Currently, when a user deletes a directory (e.g. /dav/directory/) in Cyberduck issues recursively PROPFIND requests to find all the files and directories inside. Then it issues DELETE requests for each of them.

Some other WebDAV clients (such as command line client cadaver - (http://www.webdav.org/cadaver/)) only issues a single PROPFIND (probably just to verify its existence?) and then a single DELETE /dav/directory/ request. It's up to the server to delete everything recursively.

I believe that this "single DELETE request" implementation is completely valid according to WebDAV RFC4918 http://www.ietf.org/rfc/rfc4918.txt (it's linked from http://www.webdav.org/) -- see section 9.6.1. DELETE for Collections.

I was wondering if you previously considered this implementation?

Thanks a lot for consideration!

A bit of background - I'm a software engineer working for a company which is running WebDAV server and some of our clients have often tens of thousands (some even hundreds of thousands) of "files" (aka properties) in "directories" (aka collections) and this would greatly improve performance of deletions (our server supports this "server-side recursive deletion" as per WebDAV RFC4918 mentioned above).
@cyberduck
Copy link
Collaborator Author

@dkocher commented

We do issue a single DELETE to recursively delete a folder but still issue PROPFIND requests for all child directories prior the delete.

@cyberduck
Copy link
Collaborator Author

e2e3c54 commented

Replying to [comment:2 dkocher]:

We do issue a single DELETE to recursively delete a folder but still issue PROPFIND requests for all child directories prior the delete.

That's unfortunately not what I observe. I just tried it with Cyberduck 5.3.3 (23221) and apart from PROPFINDs for each directory, I'm it still seeing DELETE requests for every single file & directory, e.g. like this:

PROPFIND /dav/content/test/ HTTP/1.1
PROPFIND /dav/content/test/dirA/ HTTP/1.1
PROPFIND /dav/content/test/dirB/ HTTP/1.1
PROPFIND /dav/content/test/dirC/ HTTP/1.1
PROPFIND /dav/content/test/dirD/ HTTP/1.1
PROPFIND /dav/content/test/dirD/dirX/ HTTP/1.1
DELETE /dav/content/test/bar HTTP/1.1
DELETE /dav/content/test/dirA/bar HTTP/1.1
DELETE /dav/content/test/dirA/foo HTTP/1.1
DELETE /dav/content/test/dirA/ HTTP/1.1
DELETE /dav/content/test/dirB/bar HTTP/1.1
DELETE /dav/content/test/dirB/ HTTP/1.1
DELETE /dav/content/test/dirC/foo HTTP/1.1
DELETE /dav/content/test/dirC/ HTTP/1.1
DELETE /dav/content/test/dirD/dirX/foo HTTP/1.1
DELETE /dav/content/test/dirD/dirX/ HTTP/1.1
DELETE /dav/content/test/dirD/ HTTP/1.1
DELETE /dav/content/test/foo HTTP/1.1
DELETE /dav/content/test/ HTTP/1.1
PROPFIND /dav/content/ HTTP/1.1

Since this doesn't match with the behavior you expect, I'm reopening the issue. Sorry!

Could it be because List<Path> files in here https://g.iterate.ch/projects/ITERATE/repos/cyberduck/browse/webdav/src/main/java/ch/cyberduck/core/dav/DAVDeleteFeature.java11960 doesn't have the deleted directory as the first item? Looks like the files would be a result of post-order tree traversal, i.e. the directory, which user requested to delete appears last in the files array/iterator.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

In 7b9ccaf.

@iterate-ch iterate-ch locked as resolved and limited conversation to collaborators Nov 26, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@dkocher dkocher

Labels
enhancement fixed webdav WebDAV Protocol Implementation
Projects
None yet
Milestone
5.4.1
Development

No branches or pull requests
2 participants
@dkocher @cyberduck