Expected behavior for "directory to new directory" depends on trailing slash

[Github-dm-CDE]

In Copying files and directories, 1f case "directory to new directory", it is stated that the trailing slashes in both source and target are optional. However, if source/subdir and target/newdir/ are being used, the resulting target structure is the following:

📁 target
 └── 📁 newdir
     └── 📁 subdir
          ├── 📄 subfile1
          ├── 📄 subfile2
          └── 📁 nesteddir
              └── 📄 nestedfile

Basically the subdir folder itself is taken too, not only its content.
This can be reproduced e.g. out of the box with LocalFileSystem() and the copy() method.

Is such output expected?

[martindurant]

Yes, this sounds exactly as designed, and what you would expect with a posix CLI. It also depends on whether the target directory already exists or not.

[CM000n]

Is then the behaviour specified in the documentation for single source to single target case 1f. Directory to new directoy incorrect @martindurant? Here the documentation specifies an expected output of:

cp("source/subdir/", "target/newdir/", recursive=True)
(Whether with or without trailing slashes should result in the following structure)

📁 target
 └── 📁 newdir
     ├── 📄 subfile1
     └── 📄 subfile2
         └── 📁 nesteddir
             └── 📄 nestedfile

[martindurant]

"source/subdir/"

This path contains a terminal "/", so that is probably the difference. It would be best to make the cases with and without, versus expectations, test cases to be fixed. This is obviously not simple territory.

[xebab]

The difference is definitely the trailing slash in the source path.

The thing is that the documentation explicitly states

Trailing slashes on both source and target are optional and do not affect the result.

So the first thing to clarify would be whether there is a problem in the documentation or in the implementation.

[xebab]

I think that the documentation is correct, after all. There are test cases that are supposed to test that trailing slashes are optional.

Those tests were not executed, however. After enabling them they fail in accordance with the issue reported here.