cancel file copy with overwrite

March 17, 2020 at 08:56:48
Specs: Win 10, 8GB
I have this question which I ran into on a Windows 7, but it might as well be exactly the same issue on Windows 10. It's more of a conceptual issue, but I'd like to know if anybody can add some info regarding this "issue". There's many ways of copying files, so maybe there's a difference when it concerns this issue.

Here we go:
I am copying a file. The target file already exists. Both files (before the copy) are different.
Now, the source file is a big file. It doesn't matter how big, but it is enough so that you can see the copy occur while it is happening.

In Windows explorer, you have the "Cancel" option. Not saying you must press that, but assume in this case, I'm pressing cancel in the middle of the operation.
Windows Explorer cancels the copy operation, fine.

But, what happens with the file that was about to be overwritten ?
Well, it just gets deleted.

My question basically is: is this a Windows thing ? Meaning, this is intended behaviour, no matter what copy method you use, whatever File System you have.

Or, is this linked to the File System (FAT, NTFS, ...), or is it linked to the copy-operation ?


See More: cancel file copy with overwrite

Reply ↓  Report •

#1
March 17, 2020 at 10:01:54
Are you saying that the source file (the one to be copied/duplicated) having been temporarily duplicated or whatever "somewhere within windows" for the purpose of copying to a new location....is deleted when you cancel the copy/paste process - but also the original one is deleted as well?

I don't ever recall the "original" version being being deleted/lost when I was using windows - at least as far as win-7 professional - and the copy/paste operation was cancelled.

The destination existing copy still remained whenever I cancelled a cop/paste routine.

Edit to clarify...

The destination existing copy would remain untouched if I attempted to paste a file with “exactly” the same name to that same location - and then cancelled the copy/paste process.

message edited by trvlr


Reply ↓  Report •

#2
March 17, 2020 at 12:04:51
I don't recall ever cancelling the copy of a lage file, and know
nothing about how it is supposed to work. But I can speculate...

I'm surprised that your experience is that the destination file
is deleted, unless you just cancelled too late. The progress bar
or graph or whatever is displayed to show the progress of the
copying might be slightly behind what is happening. It could
show that it still has a few seconds to go when it is actually
re-writing the directory at that instant. Could you just have
been a moment too late?

It seems like a pretty obvious design consideration to avoid
wiping out the destination file and its record in the directory
unless and until all the storage space is used up, and there
is no place to copy the file except physically over the old one.
That would be mighty tight.

-- Jeff, in Minneapolis

message edited by Jeff Root


Reply ↓  Report •

#3
March 17, 2020 at 12:16:42

Reply ↓  Report •

Related Solutions

#4
March 17, 2020 at 13:13:25
Color me confused.

You said: "I am copying a file. The target file already exists. "
You also so said: "But, what happens with the file that was about to be overwritten ?"

AFAIK "Copying a file" means to make an exact duplicate of an existing file.

Right-Click, Copy...Right-Click, Paste (or Ctrl-c, Ctrl-v)

What kind of "copy" are you doing that overwrites an existing file?


message edited by DerbyDad03


Reply ↓  Report •

#5
March 17, 2020 at 14:00:45
What Looge appears to be doing is something I do
fairly often: Replace an existing file with a newer one from
another location. I just don't recall ever interrupting the copy
midway.

-- Jeff, in Minneapolis


Reply ↓  Report •

#6
March 17, 2020 at 15:10:03
I’ve dun wot Jeff is suggesting, and cancelled it before completion. I don’t recall ever losing the copy already at the target destination... But fair to say it’ bin a whyle since...

Even the surely the newer version would still be in its own location after the cancellation?

The caveat is if it was a cut ‘n paste operation... That might conceivably result in a loss of the original; which I think I have had happen. Generally I do a copy routine and once the new location is safe, then perhaps delete the source file.

Oddly in Macs... there is no cut option, on,y copy... At least I haven’t found it yet on any of various versions of Mac OS I’m familiar with. So one is (reasonably) safe in presuming the source version is still intact?


Reply ↓  Report •

#7
March 17, 2020 at 15:43:08
I believe it has always been the case that when a move is done--
as opposed to copy and paste-- the copy of the file in the new location
is compared to the old one ("verified" in DOS) before the old one
is deleted.

-- Jeff, in Minneapolis


Reply ↓  Report •

#8
March 17, 2020 at 16:16:45
That rings a bell - that a move is different to copy 'n paste...

Reply ↓  Report •

#9
March 18, 2020 at 01:12:53
> See if this answers your question:
>
> https://www.quora.com/What-happens-...

That is interesting on itself, and it is "system dependant", possibly also FileSystem and even command-dependant ...

... but it's not the question of this thread, as it does not involve cancelling.


Reply ↓  Report •

#10
March 18, 2020 at 01:16:54
> That rings a bell - that a move is different to copy 'n paste...

That's an understatement, a move is very different from a copy. One additional thing that happens is that moving a file on the SAME disk, or moving a file to a DIFFERENT disk (not just different partition, a different physical disk), is different. Usually people have only 1 disk, and wouldnt even be able to see this, but in servers it is standard to have multiple disks. Well, it used to be anyway, virtual disks now end up being the same physical disk.

But, also that is not what this thread is about, as this concerns the/a copy command .... :)


Reply ↓  Report •

#11
March 18, 2020 at 01:26:29
> I'm surprised that your experience is that the destination file
> is deleted, unless you just cancelled too late. The progress bar
> or graph or whatever is displayed to show the progress of the
> copying might be slightly behind what is happening. It could
> show that it still has a few seconds to go when it is actually
> re-writing the directory at that instant. Could you just have
> been a moment too late?

No, it's not a timing issue. How long do you think it takes, on an average system, to copy a 20 Gig file ?

There's enough time to cancel. But you're correct in saying that it would be either hard or impossible to do the same with any "normal" file. Let's assume a regular file, being up to what, 500K ? You could probably not reproduce this issue, and that is because I think this cancel funtion (which is the one from Windows Explorer) has a time-out implemented. And that is OK ... for small files.

But for big files, it doesn't work, since the system can wait 5 seconds, 10 seconds, 20 seconds ... the file would not have been finished copying.

So, back to the timing, suppose your target disk is a memory stick, which has got an actual writing speed of 2MB/sec (and that is not a joke, that is the actual speed), now copy a 20Gig file to that disk. I think you have time go get some coffee :)

( That is just an example, but it could be an existing case, as you have USB sticks that are 64G, 128G and possibly even more, still only USB2.0, or on a USB2.0 port or hub or cable). Note that you do not need such a slow disk, I can reproduce this issue on a disk writing at 200MB/sec as well.


Reply ↓  Report •

#12
March 18, 2020 at 01:40:56
I suspect that the way copy works in this situation is:

1. Delete or overwrite current directory entry for the file. (I suspect bad consequences if you had two entries for the same file name.

2. Perform the copy.

Interrupt the process after 1, but before 2 has completed and you get the result you describe. Moral - be careful when overwriting files.


Reply ↓  Report •

#13
March 18, 2020 at 02:02:05
> Color me confused.
>
> You said: "I am copying a file. The target file already exists. "
> You also so said: "But, what happens with the file that was about to be overwritten ?"
>
> AFAIK "Copying a file" means to make an exact duplicate of an existing file.
>
> Right-Click, Copy...Right-Click, Paste (or Ctrl-c, Ctrl-v)
>
> What kind of "copy" are you doing that overwrites an existing file?


It's a regular copy, one that overwrites a file that already exists.
I have added that they are different (on content) but they could also be the same.

When you copy, doesn't matter how, and there is overwriting involved, there are 3 files :
- the source file
- the old target file
- the new target file


Reply ↓  Report •

#14
March 18, 2020 at 02:05:40
> Are you saying that the source file (the one to be copied/duplicated) having
> been temporarily duplicated or whatever "somewhere within windows" for the
> purpose of copying to a new location....is deleted when you cancel the
> copy/paste process - but also the original one is deleted as well?
>
> I don't ever recall the "original" version being being deleted/lost when I was
> using windows - at least as far as win-7 professional - and the copy/paste
> operation was cancelled.
>

I can reproduce this issue at will ...
I'm also going to try and reproduce using command line.
The original file - aka the source file - is never deleted, obviously. That file is only read.

> The destination existing copy still remained whenever I cancelled a
> cop/paste routine.
>
> Edit to clarify...
>
> The destination existing copy would remain untouched if I attempted
> to paste a file with “exactly” the same name to that same location -
> and then cancelled the copy/paste process.

Can you state the details of your test case ? What is the size of your file, what is the time it takes to perform such a copy, without cancelling ?

message edited by Looge


Reply ↓  Report •

#15
March 18, 2020 at 02:28:10
I have a vague yet strong memory that when a file is
written to a drive, an entry is first made in the directory,
with a marker indicating that the file hasn't been written
yet. The file is then written. If it is a move, the file is
then read and compared to the original. If it is okay,
then the directory is updated to put a marker in the entry
for the file being overwritten and remove the marker from
the entry for the new file. It would be almost impossible
to interrupt the process while writing to the directory, and
doing so might require the use of a hammer. As long as
no part of the file is actually overwritten due to a shortage
of storage space, the operation can be cancelled at any
time before that final write to the directory without a loss
of data. The OS would probably complain about a lack
of available space rather than overwriting the old file.

-- Jeff, in Minneapolis


Reply ↓  Report •

#16
March 18, 2020 at 03:04:59
I suspect the result also depends upon the filesystem used on the destination drive. NTFS is much more resilient than FAT and has journalling, which means it can roll back changes.

Edit: No. I've done an experiment and with NTFS as destination the destination file is deleted before the copy completes. So if you cancel the operation the existing destination file is deleted. But that seems fair enough - you were asked whether you were sure that you wanted to overwrite the destination.

So:

1. You ask the system to copy a file.

2. The system tells you "that file already exosts, are you sure that you want to overwrite it?"

3. You answer "yes".

4. The system deletes the original in the destination and starts to copy the new version.

5. You change your mind.

6. Rather than leave a part-copied file the system deletes it (but leaves the source that you were copying unchanged).

Sounds fine to me. How many times do you want to be asked whether you mean what you say? What do you do about it? You restore the deleted file from your backup (you do keep backups don't you?) - simple.

message edited by ijack


Reply ↓  Report •

#17
March 18, 2020 at 07:56:12
The irony is that the issue I'm discussing here, can be a backup issue itself. If the behaviour is Windows general, it can also be an issue with any 3rd party software, including professional backup system.

How many times this issue would or could occur, I personally find irrelevant. It's like asking : hey, this wiring on our airplane may cause an issue one day, but I think it's OK because the chance is very low. You know it's an issue, then you have a choice to fix or to leave it.

This issue is in fact a logical data integrity issue, and the point is to find out why this is happening. This specific case is about total file loss, not just logical file corruption. See https://en.wikipedia.org/wiki/Data_... for more on Data Integrity

On which level is it caused, is what I'm interested about.

My solution to this ? I'm not going to cancel many copies, but a general copy command may fail for several reasons. You see, in this case we're copying 1 file, but that is only to indicate the issue. What will be really going on, is that full file structures would be copied, in which this one file is a part of that structure.

Ever seen a laptop go in Hibernation ? What do you think would happen in such a case ? Especially when the target drive may just not be there anymore on restart. Or, ever had a USB drive disconnected by accident (either the power or the USB cable) ?


Reply ↓  Report •

#18
March 18, 2020 at 08:07:15
> So if you cancel the operation the existing
> destination file is deleted. But that seems fair enough - you were asked whether you
> were sure that you wanted to overwrite the destination.

That's dependant on how you see it. I do agree a file may be overwritten ... bu then I also want it to be overwritten by the new file.

It literally states "a file being overwritten". If it is deleted, where is my overwritten file ?

Did it ask to remove a file ? No.


Reply ↓  Report •

#19
March 18, 2020 at 08:10:43
This is the script I used to test this case. Tested on Windows 7 and 10, used COPY and XCOPY, filesystem is NTFS. Not tested on FAT because the irony would be that a journalling system like NTFS would actually be more suited for that, unlike FAT.

The source file must be a big file, or your writing device must be slow enough so that the whole copy takes at least some 10 or 20 seconds, but preferably somewhat more.

@echo on

explorer .

@ver

dir the_source_file.dat

echo I am the old targetfile > the_target_file.dat

dir the_target_file.dat

REM Now CTRL-C
xcopy the_source_file.dat the_target_file.dat /Y

REM Resume this script by answering N
dir the_target_file.dat


Reply ↓  Report •

#20
March 18, 2020 at 08:38:09
You want the file to be overwritten with the new file - then why cancel the operation?

Just how much hand-holding do you need? I guess that if you cancel the operation it should say "do you want me to restore the original file?", and then "are you sure?", "you haven't changed your mind at the last minute?", etc.

Anyway, there's no problem as you have your backups. This sort of situation is exactly why you make them, so use them.


Reply ↓  Report •

#21
March 18, 2020 at 09:26:14
Without having looked at this question recently, or ever having
looked at it on NTFS or other journalling file system, I find it
impossible to believe that the file is actually deleted in this
scenario unless, as I said, you run out of disk space, and I
think in that case, as I also said, Windows would complain
that there is insufficient space rather than actually physically
overwriting the old target file. Instead, as I also also said, I
think it just overwrites the first character of the filename in the
directory to make the file invisible to most access functions.
Resurrecting a file after deletion just requires another tool,
plus a new initial character for the filename.

On the other hand, I also used an Apple IIe a lot, and that
could be what I'm recalling, instead of DOS and Windows.

-- Jeff, in Minneapolis


Reply ↓  Report •

#22
March 18, 2020 at 09:39:30
You are quite correct that - at least on a FAT filesystem - most of the data and metadata to recover a file is still there after it is deleted. I'm not sure what happens on NTFS, the workings of which are something of a closed book. But, as you say, additional tools are required to salvage, or attempt to salvage, this information.

It should be unnecessary nowadays. It's far quicker, and more reliable, to just reload the file from your backups.


Reply ↓  Report •

Ask Question