Copy to webdav remote creates spurious directories

What is the problem you are having with rclone?

'copy'ing a tree from my Linux box to a webdav remote creates spurious empty directories. Say I have three subdirs (test{a..c}) with five files in each. I copy that tree and I get a tree on the remote with fifteen dirs, three are "test{a..c}" with the resp files in them and the others are empty directories "test{a..c} ({1..4})". The numbers are in real parentheses. There is no error message and there are no warnings either. On the Linux side all looks as if it went well but on the remote there are all those additional empty directories.

Run the command 'rclone version' and share the full output of the command.

rclone v1.61.1

  • os/version: debian 10.13 (64 bit)
  • os/kernel: 5.10.0-9mx-amd64 (x86_64)
  • os/type: linux
  • os/arch: amd64
  • go/version: go1.19.4
  • go/linking: static
  • go/tags: none

Which cloud storage system are you using? (eg Google Drive)

A webdav server on a remote machine.

The command you were trying to run (eg rclone copy /tmp remote:tmp)

rclone -P copy localDir webdav:localDir

I am not sure whether this is an rclone bug, a feature of the way rclone works or some problem with the webdav server.


  • post the redacted config file
  • can you re-create the issue on single file. add -vv and post the entire output
type = webdav
url = http://ags2.rt:12345
user = Admin

The webdav server runs on an Android phone on the local network.

2023/02/13 16:47:32 DEBUG : rclone: Version "v1.61.1" starting with parameters ["XX/bin/rclone" "-P" "-vv" "copy" "." "android:"]
2023/02/13 16:47:32 DEBUG : Creating backend with remote "."
2023/02/13 16:47:32 DEBUG : Using config file from "XX/.config/rclone/rclone.conf"
2023/02/13 16:47:32 DEBUG : fs cache: renaming cache item "." to be canonical "/ram/test"
2023/02/13 16:47:32 DEBUG : Creating backend with remote "android:"
2023-02-13 16:47:33 DEBUG : zz: Need to transfer - File not found at Destination
2023-02-13 16:47:34 DEBUG : zz: md5 = aee713156ca55da1b07652f1d7614ae9 OK
2023-02-13 16:47:34 INFO  : zz: Copied (new)
Transferred:       52.854 KiB / 52.854 KiB, 100%, 52.832 KiB/s, ETA 0s
Transferred:            1 / 1, 100%
Elapsed time:         2.7s
2023/02/13 16:47:34 INFO  : 
Transferred:       52.854 KiB / 52.854 KiB, 100%, 52.832 KiB/s, ETA 0s
Transferred:            1 / 1, 100%
Elapsed time:         2.7s

2023/02/13 16:47:34 DEBUG : 5 go routines active

The file is transferred and arrives in perfect shape.

ok, need to re-create the error and post a full debug log.

Well, as I said from rclone's perspective there was no error message at all.

I will later (or tomorrow) try to create a copy as outlined in my OP and post the log.

This will be rclone trying to create an already existing directory and the server, instead of giving an error message like it should, creates a new directory with a numeric suffix.

So I'd say this is a bug in the webdav server.

However you can workaround it by using --transfers 1 - that should work.

@ncw Yep, that was one of the possibilities I was thinking of. The server is a pretty basic affair (though functional, other than this glitch) so that's entirely possible. For the moment it's not a big deal as I can easily search on the Android side for directories ending in "(\d+)$", luckily no directory in the (pretty convoluted) tree ends with that pattern :smile:

I can't immediately test the --transfer workaround but will do so later. We'll see. Thanks for the time being.

You could also use rclone rmdirs after the transfer to delete any empty directories.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.