Cut-and-paste in Explorer (the Windows graphical shell) works exactly the same as calling some variant of the
MoveFile API, probably specifically
MoveFileExW with flags that copying the file is allowed (as this is necessary to "move" a file across network connections or physical disk partitions) and the write-through flag, instructing the function not to return until the disk has been updated with all changes including the deletion of the old file location (for "moves" that must be implemented as copy-then-delete operations). This is also generally the same behavior you'd get using the
ren commands in
cmd.exe (those commands do the same thing), dragging-and-dropping the file in Explorer, or so on. The system will perform a rename, rather than a physical move, if possible, as this is much faster.
Any successful move operation will mean the file is no longer reachable at its old path/name, effective instantly when the operation succeeds. However, the "deletion" done by a copy-and-delete "move" will leave the file's contents on the disk, and merely remove the file system entry and mark the space as free; any new data written to the disk may overwrite that space, but until it does, an attacker with low-level access to the disk could bypass the file system and access the file contents by reading the disk as a block device. "Moves" that take place within a single partition and are therefore simply implemented as a rename don't even change the physical location on the disk, only the logical path through the file system that points to the file's physical location. If you want to do a more thorough deletion - for example, by overwriting the file's old location - you should use an explicit Copy operation (
CopyFileW, or copy-and-paste, or the
copy command, etc.) and then perform your thorough delete operation on the old path.