'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.
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
I can't immediately test the --transfer workaround but will do so later. We'll see. Thanks for the time being.