Copying and pasting nested folders flattens the copied folders in the destination
Closed this issue · 6 comments
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
- Open a folder with one or more subfolders in Tree View
- 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
- 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 #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)
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.
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'
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?
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
Closing as wontfix as Tree View behavior is consistent with that of major OSes.