I notice that in the Undo history it also includes as Moves, items I moved in and cancelled because they would have overwritten an existing file.
It's useful to know they were cancelled but this I would think becomes a bug in that it offers an Undo for it when no action was in fact taken. Clicking the Undo would if clicked I presume move the pre-existing file.
I'm not sure if this is a trivial thing to correct. If it is it's worth doing, I often use the Undo History to review my actions to make sure I didn't mis-move or mis-delete anything. If it's not trivial it's not high priority. I presume it would be much easier to fix this when you implement a native move/copy rather than trying to work out what the system move/copy carried out, although these were a drag from Explorer into Everything, which I suppose might require seeing if the target files actually changed.
d
Undo History : Cancelled ops
-
void
- Developer
- Posts: 19899
- Joined: Fri Oct 16, 2009 11:31 pm
Re: Undo History : Cancelled ops
The Windows shell handles the drop.
Everything receives no information on the file operations performed.
Everything only knows the intended operation (move / copy / create shortcut).
Please try the Index Journal to view the performed file operations.
Moves and renames can be undone here.
Everything receives no information on the file operations performed.
Everything only knows the intended operation (move / copy / create shortcut).
Please try the Index Journal to view the performed file operations.
Moves and renames can be undone here.
-
meteorquake
- Posts: 628
- Joined: Thu Dec 15, 2016 9:44 pm
Re: Undo History : Cancelled ops
There's a parallel situation to this in terms of when you cancel an undo.
If I drag a file from R: drive (exFAT) to my D: drive (NTFS) it duly copies it. Under Edit Undo it lists it for undoing, and also in the undo history.
If I hit undo it asks for confirmation, and if I cancel it the action should still remain in the Undo, but obviously it assumes the user went ahead and doesn't know it was in fact cancelled (potentially it could find out though).
Hopefully both these scenarios will be resolved when Everything implements its own move/copy rather than relying on the windows dialog.
I think that would have another benefit - the windows move/copy can hang for a long time after a copy of numerous files, doing whoever-knows-what, which is a situation Everything duplicates, by contrast if you perform the action in something like the 7zip file manager that blazes through without any hanging at all. I think additionally it could be implemented asynchronously, as at the moment an Everything window gets locked during a large copy.
If I drag a file from R: drive (exFAT) to my D: drive (NTFS) it duly copies it. Under Edit Undo it lists it for undoing, and also in the undo history.
If I hit undo it asks for confirmation, and if I cancel it the action should still remain in the Undo, but obviously it assumes the user went ahead and doesn't know it was in fact cancelled (potentially it could find out though).
Hopefully both these scenarios will be resolved when Everything implements its own move/copy rather than relying on the windows dialog.
I think that would have another benefit - the windows move/copy can hang for a long time after a copy of numerous files, doing whoever-knows-what, which is a situation Everything duplicates, by contrast if you perform the action in something like the 7zip file manager that blazes through without any hanging at all. I think additionally it could be implemented asynchronously, as at the moment an Everything window gets locked during a large copy.