Cyberduck Mountain Duck CLI

#9798 closed enhancement (fixed)

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

Reported by: petrkotek Owned by: dkocher
Priority: normal Milestone: 5.4.1
Component: webdav Version: 5.2.2
Severity: normal Keywords:
Cc: Architecture:
Platform:

Description

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).

Change History (8)

comment:1 Changed on Jan 13, 2017 at 2:12:43 PM by dkocher

  • Milestone set to 6.0
  • Owner set to dkocher
  • Status changed from new to assigned
  • Summary changed from WebDAV: Use single DELETE for a directory rather than many PROPFINDs & DELETEs to Use single DELETE for a directory rather than many PROPFINDs & DELETEs

comment:2 follow-up: Changed on Jan 13, 2017 at 2:13:59 PM by dkocher

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

comment:3 Changed on Jan 16, 2017 at 1:37:49 PM by dkocher

  • Resolution set to worksforme
  • Status changed from assigned to closed

comment:4 Changed on Jan 16, 2017 at 1:37:57 PM by dkocher

  • Milestone changed from 6.0 to 5.3

comment:5 in reply to: ↑ 2 Changed on Jan 29, 2017 at 11:54:41 PM by petrkotek

  • Resolution worksforme deleted
  • Status changed from closed to reopened

Replying to 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.java#44 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.

comment:6 Changed on Jan 30, 2017 at 12:59:14 PM by dkocher

  • Milestone changed from 5.3 to 6.0
  • Status changed from reopened to new

comment:7 Changed on Mar 24, 2017 at 9:43:52 PM by dkocher

  • Resolution set to fixed
  • Status changed from new to closed

In r38497.

comment:8 Changed on Apr 3, 2017 at 8:52:04 AM by dkocher

  • Milestone changed from 6.0 to 5.4.1
Note: See TracTickets for help on using tickets.
swiss made software