XY wrongly moves source folder along with its files
Posted: 09 Dec 2024 03:35
Windows 10 x64, XY v26.70.0110
Not replicable so unlikely to be directly fixable but I think it's an XY bug and is remarkable enough to mention as a data point.
I had the tree and two list panes open. The left pane showed the contents of my PC's "Downloads" folder (69 files). The right pane showed contents of a folder on an external USB drive.
Note that I had years ago relocated the system Downloads folder from "C:\User whatever" to D:. So my goal was to move all files from D:\Downloads to the external drive.
I manually selected the files in D:\Downloads by first selecting the file at the top of the list then scrolling down and shift-selecting the one at the bottom. FWIW I did not use Ctrl-A, so there's no way that I accidentally selected anything but those 69 files.
I then right-clicked & held on the body of selected files and dragged them to the right pane where I chose "Move here" from the drop-down that appeared when I released the mouse right-button.
XY moved the files as usual. I have done the same thing between the same folders many times before, including earlier in the day. However, this time XY also moved the parent D:\Downloads folder! Now empty, that Downloads folder ended up on the external drive right in with the files that had been moved.
To be extra clear, that D:\Downloads folder had not been selected - only the files within it. That was done in a list pane, not in the tree. However, it seemed as if XY had thought that the parent folder too had been selected and moved it also after moving all its files.
So, immediately in the left pane, XY began showing that the D:\Downloads folder it had been viewing was gone. Both XY and Windows Explorer confirmed that the Downloads folder, with its blue arrow, was now on the external drive. Although, when trying to open that folder, XY looked for its contents in C:\XY\Downloads ie. in its own folder. So, all messed up.
I chose to restore the whole system from an image backup which fixed it all.
Only mentioned in case it coincides with some other report some day or helps Don recognize a code path to such an event.
Not replicable so unlikely to be directly fixable but I think it's an XY bug and is remarkable enough to mention as a data point.
I had the tree and two list panes open. The left pane showed the contents of my PC's "Downloads" folder (69 files). The right pane showed contents of a folder on an external USB drive.
Note that I had years ago relocated the system Downloads folder from "C:\User whatever" to D:. So my goal was to move all files from D:\Downloads to the external drive.
I manually selected the files in D:\Downloads by first selecting the file at the top of the list then scrolling down and shift-selecting the one at the bottom. FWIW I did not use Ctrl-A, so there's no way that I accidentally selected anything but those 69 files.
I then right-clicked & held on the body of selected files and dragged them to the right pane where I chose "Move here" from the drop-down that appeared when I released the mouse right-button.
XY moved the files as usual. I have done the same thing between the same folders many times before, including earlier in the day. However, this time XY also moved the parent D:\Downloads folder! Now empty, that Downloads folder ended up on the external drive right in with the files that had been moved.
To be extra clear, that D:\Downloads folder had not been selected - only the files within it. That was done in a list pane, not in the tree. However, it seemed as if XY had thought that the parent folder too had been selected and moved it also after moving all its files.
So, immediately in the left pane, XY began showing that the D:\Downloads folder it had been viewing was gone. Both XY and Windows Explorer confirmed that the Downloads folder, with its blue arrow, was now on the external drive. Although, when trying to open that folder, XY looked for its contents in C:\XY\Downloads ie. in its own folder. So, all messed up.
I chose to restore the whole system from an image backup which fixed it all.
Only mentioned in case it coincides with some other report some day or helps Don recognize a code path to such an event.