Copying and pasting nested folders flattens the copied folders in the destination

[wesrobin]

Prerequisites

• Put an X between the brackets on this line if you have done all of the following:
  • Reproduced the problem in Safe Mode: http://flight-manual.atom.io/hacking-atom/sections/debugging/#using-safe-mode
  • Followed all applicable steps in the debugging guide: http://flight-manual.atom.io/hacking-atom/sections/debugging/
  • Checked the FAQs on the message board for common solutions: https://discuss.atom.io/c/faq
  • Checked that your issue isn't already filed: https://github.com/issues?utf8=✓&q=is%3Aissue+user%3Aatom
  • Checked that there is not already an Atom package that provides the described functionality: https://atom.io/packages

Description

If a folder and (one or more of) its subfolders are selected and copied then pasted elsewhere, both selected folders are flattened and copied independently to the destination. The parent folder in the destination still contains the subfolder as expected. This is recursive and applies to subfolders of subfolders etc.

Steps to Reproduce

1. Open a folder with one or more subfolders in Tree View
2. Select the parent folder as well as one of the subfolders, and copy it, as below (bold refers to directories included in the copy)

dirA
  * subDirA
  * subDirB
dirB

3. Paste the copied selection into another directory - dirB in this case (not one of the folders within the same parent folder as this will cause the problem described in Copying and pasting directories inside themselves has undesirable results #656) .

Expected behavior:

dirA
  * subDirA
  * subDirB
dirB
  * dirA
    * subDirA

Actual behavior:

dirA
  * subDirA
  * subDirB
dirB
  * dirA
    * subDirA
  * subDirA

Reproduces how often:
Always.

Versions

$ atom --version
Atom    : 1.27.2
Electron: 1.7.15
Chrome  : 58.0.3029.110
Node    : 7.9.0

$ apm --version
apm  1.19.0
npm  3.10.10
node 6.9.5 x64
atom 1.27.2
python 2.7.13
git 2.15.2

Additional Information

OS: Mac OSX V10.13.5 (High Sierra)

[rsese]

Thanks for the report! I can reproduce on macOS 10.12.6 with Atom 1.30.0-dev-26cd4a07d.

Besides #656 which you mentioned, x-ref #509, another directory copying issue.

[winstliu]

New behavior with #1173 merged (running tree-view SHA 90f1fc0 on Windows 10 x64) has the entire directory of dirA being copied to dirB/dirA, as well as subdirA being copied to dirB/subdirA.

Unfortunately I can't figure out what Windows would do in this situation as I can't select both dirA and subdirA simultaneously in Explorer.

[winstliu]

Update: with Copy-Item dirA,dirA/subdirA dirB, I get the following:

test
├───dirA
│   ├───subdirA
│   └───subdirB
└───dirB
    ├───dirA
    └───subdirA

With Copy-Item dirA,dirA/subdirA dirB -Recurse:

test
├───dirA
│   ├───subdirA
│   └───subdirB
└───dirB
    ├───dirA
    │   ├───subdirA
    │   └───subdirB
    └───subdirA

Same for both if I specify dirA/subdirA before dirA.

On Ubuntu 16.04, I get the following using cp -r dirA dirA/subdirA dirB:

test
├── dirA
│   ├── subdirA
│   └── subdirB
└── dirB
    ├── dirA
    │   ├── subdirA
    │   └── subdirB
    └── subdirA

With cp -r dirA/subdirA dirA dirB:

cp: will not create hard link 'dirB/dirA/subdirA' to directory 'dirB/subdirA'

[winstliu]

Given the above, I'm tempted to close this as wontfix as it behaves the same as Windows and Ubuntu.

@rsese: could you give this a quick test on macOS as well?

[rsese]

On macOS 10.12.6 with cp -r dirA dirA/subdirA dirB the result is:

test
├── dirA
│   ├── subdirA
│   └── subdirB
└── dirB
    ├── dirA
    │   ├── subdirA
    │   └── subdirB
    └── subdirA

With cp -r dirA/subdirA dirA dirB, the result is also:

test
├── dirA
│   ├── subdirA
│   └── subdirB
└── dirB
    ├── dirA
    │   ├── subdirA
    │   └── subdirB
    └── subdirA

[winstliu]

Closing as wontfix as Tree View behavior is consistent with that of major OSes.