You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Dec 15, 2022. It is now read-only.
A
| A
| | x
|
| A0
| | A
| | | x
| | x
|
| A1
| | A
| | | x
| |
| | A0
| | | A
| | | | x
| | | x
| | x
| x
The paste operation is looking at the source path at the moment of pasting, which is unintuitive. I would expect it to store a list of all file paths at the moment of copying.
I'm not familiar with the exact effects of #631 but in 1.2.2, the effects of selecting the pasted item can be disastrous:
Select a folder A with file x.
Perform a copy, then perform a paste.
Select the folder A/A.
Perform a paste.
The following structure results:
A
| A
| | A
| | | A
| | | | A
| | | | | A
| | | | | | A
...
| | x
| x
Atom locks up and continues making empty A directories until the application is forcibly closed.
When reproducing this issue, it's very easy to end up with file paths so long that Windows is unable to delete them. I found rimraf very helpful in cleaning up afterward.