Have my files been correctly copied to my USB-pin?

[Oblivion77]

Good day everyone

Yesterday I copied som files to my USB-ind, they were in total a couple of megabyte.
I waited till every file had finished copying and the status-window closed by itself after reaching 100%.

A couple of minutes, after I was done copying, I copied the files from the USB-pin to my desktop, so that I always can see later if the files was complete and not corrupted.

After that, I pressed “eject” in the right-click-function on my USB-pin.

When I did that, a warning-window appeared. I cannot recall exactly what it said, but it said something about, that data was still in use and ejecting or taking out USB-pin could result in loss of data. I had none of the copied files open. I was presented with some options (try again) – (continue) – (exit) .. and some more options. I have not been able to find a similar warning through a google search.

I thought the warning came because, there were some files still in the cache who were not copied after all or because there were still files in the right-click-cut-function-folder. Do you have other suggestions, why the warning appeared?

Now I am sitting here, not totally sure if I pressed (try again) or (continue), as in mentioned above.
But I pressed one of those two.

It then came up with the message that the hardware was safely ejected and safe to remove.

I then plugged in my USB-pin again, and checked if all the files were there, which they were. I then pressed eject, and it ejected in first try without problems.

My questions are:

1 ) What would have happened if I pressed (continue), instead of ( try again ) ?

2 ) How can I see if a file has turned corrupt?

3 ) How can I see if a file has been copied correct?

4 ) When I look in file properties, and look and the file size, can that information then be not correct?
Does it only show what the file-size is supposed to be? And not what it actually is?
If the file has not completed the copying, would it then show something different than if it was copied correct and complete?

Thanks a lot in advance for all your answers

Best regards

Emil

 

[canadianvice]

Windows 10?

So:

1. Often it'll be a background process that has locked the key down and demanded it stay in the computer. Something to understand about why you eject a USB is because they are formatted so the computer can write to them at convenience. Ejecting tells it to finish the job now, rather than waiting. Your best bet, if it's really persistent, is to log off and remove the USB at this point. That'll force the issue.

I don't think your files would have been damaged. Continue tells it to ignore the error, try again tells it to... try again. A protip from my days in high school where I did this and it went badly: never cut files to a removable device. Always copy them. You can delete what is there if it's done properly, but you can't get it back if the process fails halfway through.

2. The easiest way to look at the file. For images or video, corrupted files will often either not play back (for reasons of "could not open file" not things like codecs) or they will show corruption in the image displayed such as discolouration or specking. For text files, they may fail to open or characters will be out of place. Many files will simply fail to open or recognize as the right filetype in the program they'd normally open with, if they're corrupt.

3. An expansion on #2, but you can usually use a file hash, provided you keep your original file and the copied one around long enough to do this. Hence why I suggest copying. For the most part, this isn't worth doing, but if you're paranoid, what you can do is the following, on a Windows system:

Go to start, and type in "Powershell". Just powershell - don't take the ISE option that may show.
Now, with your file, hold left-shift and right click; select "Copy as path". To get the hash of your file (this basically is a way of qualifying your file where small differences lead to huge changes in the hash - hence, different hashes mean different file contents, and this means probable corruption, if they should be the same), do the following command in powershell:

GET-FILEHASH <(right click in the window, it should paste the path you copied)/alternatively you can manually type the file path> -algorithm "MD5"

And hit enter. Do this for the other file as well. If those strings of letters and numbers come back and match, your files are identical. If they do not, something is different, and possibly this means corruption. I'd only bother going this far if you have good reason to suspect something went wrong though.

For instance, on my computer, I might type:
GET-FILEHASH "D:\Desktop\GPA Stats .... .txt" -algorithm "MD5", which gives:

Algorithm Hash Path
--------- ---- ----
MD5 06E5AF22ED7D2BF0DE2D05C9622E7E1C D:\Desktop\GPA Stats - 2018-...

Now, I made a copy and changed it. Doing this with the new one, I get:
GET-FILEHASH "D:\Desktop\GPA Stats ... .txt" (the copy) -algorithm "MD5", which gives:

Algorithm Hash Path
--------- ---- ----
MD5 8FA437EAC00EB0AE192721584DABA408 D:\Desktop\GPA Stats - 2018-05-09 - Copy.txt

Compare: 06E5AF22ED7D2BF0DE2D05C9622E7E1C (original) with 8FA437EAC00EB0AE192721584DABA408 (changed file) and you'll notice those values are not the same! Something happened! (In this case, I deliberately removed some text in the file, but you get the point)



4. Filesize would be one quick giveaway something happened, if it's significantly deviant from expectations (again, a good reason to keep the original until you know). This is calculated dynamically, meaning that the OS just does it when you call up the info - it will always reflect the most recent file size.

If it failed to copy properly, often:
- It may simply not show at all
- It may have small differences such as file size mentioned above
- It will almost certainly have a different file hash

 

[Oblivion77]

First of all, thank you for making such a thorough reply!

Windows 10?

- Yes

1. Often it'll be a background process that has locked the key down and demanded it stay in the computer. Something to understand about why you eject a USB is because they are formatted so the computer can write to them at convenience. Ejecting tells it to finish the job now, rather than waiting. Your best bet, if it's really persistent, is to log off and remove the USB at this point. That'll force the issue.

I don't think your files would have been damaged. Continue tells it to ignore the error, try again tells it to... try again. A protip from my days in high school where I did this and it went badly: never cut files to a removable device. Always copy them. You can delete what is there if it's done properly, but you can't get it back if the process fails halfway through

- I always use COPY
- Continue function tells it to ignore the error or force it to eject?

2. The easiest way to look at the file. For images or video, corrupted files will often either not play back (for reasons of "could not open file" not things like codecs) or they will show corruption in the image displayed such as discolouration or specking. For text files, they may fail to open or characters will be out of place. Many files will simply fail to open or recognize as the right filetype in the program they'd normally open with, if they're corrupt.

- File on my drive (a) that I copy to my USB-pin (b) and then I copy that file from my USB-pin to my desktop (c)
- If file (b) was corrupt, would it show that in file (c) aswell?

3. An expansion on #2, but you can usually use a file hash, provided you keep your original file and the copied one around long enough to do this. Hence why I suggest copying. For the most part, this isn't worth doing, but if you're paranoid, what you can do is the following, on a Windows system:

- As in above, can I check the hash in file (c) to see if something is wrong with file (b)?

4. Filesize would be one quick giveaway something happened, if it's significantly deviant from expectations (again, a good reason to keep the original until you know). This is calculated dynamically, meaning that the OS just does it when you call up the info - it will always reflect the most recent file size.

- So if it had not completed copying, the filesize on file (a) and file (b) would be different?

 

[canadianvice]

First of all, thank you for making such a thorough reply!

Windows 10?

- Yes

1. Often it'll be a background process that has locked the key down and demanded it stay in the computer. Something to understand about why you eject a USB is because they are formatted so the computer can write to them at convenience. Ejecting tells it to finish the job now, rather than waiting. Your best bet, if it's really persistent, is to log off and remove the USB at this point. That'll force the issue.

I don't think your files would have been damaged. Continue tells it to ignore the error, try again tells it to... try again. A protip from my days in high school where I did this and it went badly: never cut files to a removable device. Always copy them. You can delete what is there if it's done properly, but you can't get it back if the process fails halfway through

- I always use COPY
- Continue function tells it to ignore the error or force it to eject?

2. The easiest way to look at the file. For images or video, corrupted files will often either not play back (for reasons of "could not open file" not things like codecs) or they will show corruption in the image displayed such as discolouration or specking. For text files, they may fail to open or characters will be out of place. Many files will simply fail to open or recognize as the right filetype in the program they'd normally open with, if they're corrupt.

- File on my drive (a) that I copy to my USB-pin (b) and then I copy that file from my USB-pin to my desktop (c)
- If file (b) was corrupt, would it show that in file (c) aswell?

3. An expansion on #2, but you can usually use a file hash, provided you keep your original file and the copied one around long enough to do this. Hence why I suggest copying. For the most part, this isn't worth doing, but if you're paranoid, what you can do is the following, on a Windows system:

- As in above, can I check the hash in file (c) to see if something is wrong with file (b)?

4. Filesize would be one quick giveaway something happened, if it's significantly deviant from expectations (again, a good reason to keep the original until you know). This is calculated dynamically, meaning that the OS just does it when you call up the info - it will always reflect the most recent file size.

- So if it had not completed copying, the filesize on file (a) and file (b) would be different?

Personally, I don't recall ever seeing continue as an option. Usually it just told me it was in use and to try later. Typically however, that's what continue means.

Re #2: Computers cannot divine bits where they don't exist, so yes, if B was corrupt, C would be corrupt. However, given that corruption can occur during making a copy of B to C, this does not necessarily logically imply that B is a corruption of A. The only way to be sure is to check any children against the file that is effectively the "master".

Re #3: So, technically, no. C does not logically imply something is wrong with B, so if we're needing 100% certainty here, as above, the only way to determine which files are damaged is by checking them with known good files, which typically means the master they spawned from. Realistically, if there's an issue with C, it's probably present in B as well. A hash does not evaluate file integrity or corruption. It evaluates sameness-of-data. However, if two files should be the same and they are not, then you probably can ascertain that some sort of issue has occurred.

Basically, the logic you need to use for this is: Am I checking a file against one I know to be good? If you aren't, then you cannot be certain.

Re #4: Here's the thing: Windows often just aborts failed operations. HOWEVER, if it somehow it was, then a filesize difference is probable.

 

[Oblivion77]

Personally, I don't recall ever seeing continue as an option. Usually it just told me it was in use and to try later. Typically however, that's what continue means.

I did not understand your last sentence. What does continue typical means?

Re #2: Computers cannot divine bits where they don't exist, so yes, if B was corrupt, C would be corrupt. However, given that corruption can occur during making a copy of B to C, this does not necessarily logically imply that B is a corruption of A. The only way to be sure is to check any children against the file that is effectively the "master".

I do not have the USB-pin at the moment, and therefor cannot check file B. But I can still safely assume, that when file C is good, then B should be good aswell?

Re #4: Here's the thing: Windows often just aborts failed operations. HOWEVER, if it somehow it was, then a filesize difference is probable.

How does Windows abort? And what happens when it aborts?

Again, thank you for taking time to answer

 

[canadianvice]

Personally, I don't recall ever seeing continue as an option. Usually it just told me it was in use and to try later. Typically however, that's what continue means.

I did not understand your last sentence. What does continue typical means?

Re #2: Computers cannot divine bits where they don't exist, so yes, if B was corrupt, C would be corrupt. However, given that corruption can occur during making a copy of B to C, this does not necessarily logically imply that B is a corruption of A. The only way to be sure is to check any children against the file that is effectively the "master".

I do not have the USB-pin at the moment, and therefor cannot check file B. But I can still safely assume, that when file C is good, then B should be good aswell?

Re #4: Here's the thing: Windows often just aborts failed operations. HOWEVER, if it somehow it was, then a filesize difference is probable.

How does Windows abort? And what happens when it aborts?

Again, thank you for taking time to answer

1. "Typically": usual, common, frequent. Basically, I'm saying that if you see an option for "Continue" in regard to error messages, it usually means to try pushing forward in spite of the problem; that's generally how the term is used in error dialogs.

2. If C is good, that would imply B is good. You are correct in this assumption.

4. Sorry. I suspect English is a second language? No shame in that. Anyhow, by "abort" I mean, it quits what it was doing. So if the copy operation goes badly, usually windows just tries to clean up the file and act like nothing ever happened. If it did leave a file though, you could probably follow your logic and check the file sizes to see quickly and easily if it was changed or corrupted. Often though, Windows just cleans up the file and puts it back to how it was before you tried the operation in the first place.

 

[Oblivion77]

1. "Typically": usual, common, frequent. Basically, I'm saying that if you see an option for "Continue" in regard to error messages, it usually means to try pushing forward in spite of the problem; that's generally how the term is used in error dialogs.

So if I pressed eject - error message appears - I press continue - it would ignore the error message and try to eject?

4. Sorry. I suspect English is a second language? No shame in that. Anyhow, by "abort" I mean, it quits what it was doing. So if the copy operation goes badly, usually windows just tries to clean up the file and act like nothing ever happened. If it did leave a file though, you could probably follow your logic and check the file sizes to see quickly and easily if it was changed or corrupted. Often though, Windows just cleans up the file and puts it back to how it was before you tried the operation in the first place

I am danish, so your assumption is indeed right.
I wanted to know what aborting would do: Like if it would just delete the corrupted copy, leave only the copied part, or finish copying.

 

[canadianvice]

1. "Typically": usual, common, frequent. Basically, I'm saying that if you see an option for "Continue" in regard to error messages, it usually means to try pushing forward in spite of the problem; that's generally how the term is used in error dialogs.

So if I pressed eject - error message appears - I press continue - it would ignore the error message and try to eject?

4. Sorry. I suspect English is a second language? No shame in that. Anyhow, by "abort" I mean, it quits what it was doing. So if the copy operation goes badly, usually windows just tries to clean up the file and act like nothing ever happened. If it did leave a file though, you could probably follow your logic and check the file sizes to see quickly and easily if it was changed or corrupted. Often though, Windows just cleans up the file and puts it back to how it was before you tried the operation in the first place

I am danish, so your assumption is indeed right.
I wanted to know what aborting would do: Like if it would just delete the corrupted copy, leave only the copied part, or finish copying.

1. Maybe? As I said, I don't recall ever actually having seen this offered as an option. My experience has always been more finalized - it was telling me, not offering.

2. I've never had this actually happen to me that I recall. My presumption would be that this depends on how bad the fault causing the issue was. If you computer crashed halfway through, it'd probably leave a file. If something else went wrong, it would probably clean it up. Finishing copying following a fault or interruption isn't something I think Windows' default file manager does. It's gotta be the whole process or nothing.

 

[jsmithepa]

1. Windows would forcibly terminate the session that has locked the USB drive. Often, the session in question is just another window you had open to access/browse the drive and not really doing any data xfer. Next time, just close everything, and try again should do the job.

2/3. When I must be certain copies is been done correctly, not a single misplaced bit, I use TERACOPY 2.27 (newer version has a bug). This utility copies, computes the checksum, READ BACK the copied files, compare both checksums. To me, the only fire-sure way, no compromise. With an added benefit of preserving folders' dates, dang Windows Copy gives you today's date, sometimes is useful to find stuff by their original creation dates.

4. Often times, you cannot rely on the file size. Different disks may had been formatted with a different cluster size, FAT and NTFS may also do their own things.

 

[Oblivion77]

That makes sense, it would wait for the action (transfer for example) to be done

Finishing copying following a fault or interruption isn't something I think Windows' default file manager does.

Do you mean, that it would not keep copying a "broken" file, or what do you exactly mean?

 

[Oblivion77]

1. Windows would forcibly terminate the session that has locked the USB drive. Often, the session in question is just another window you had open to access/browse the drive and not really doing any data xfer. Next time, just close everything, and try again should do the job.

That was something I have not thought about. That the session still running, could just be the USB-window still open, and not a transfer still running in the background. If that is what you meant?

 

[canadianvice]

That makes sense, it would wait for the action (transfer for example) to be done

Finishing copying following a fault or interruption isn't something I think Windows' default file manager does.

Do you mean, that it would not keep copying a "broken" file, or what do you exactly mean?

Basically, if something screws up halfway through, or you stop it halfway through, the default program that does the copying on Windows (explorer.exe) does not support resuming it; you have to start again from scratch.

Honestly, computers are finicky mate - basically, the system will do what it can to avoid having a fatal problem. If it can't do that, it tries to take the next least destructive option for avoiding a problem. This is really quite rare anyway.

As for that other post you quoted, he's just saying that the thing holding up the USB being removed is typically some other program or window you've forgotten was open.

As I said before, if the USB is really not being compliant, just hit log off on your system. This will terminate any running programs that would be holding the USB hostage and so you can be guaranteed a safe removal at that point in time.

I'll be totally frank - it's rare I use the "remove USB" option, and I haven't once encountered issues for it in the time I've used a computer. This of course comes with the caveat that things can go wrong, so if it's super important it's best not to jeopardize it that way.

 

[Oblivion77]

Basically, if something screws up halfway through, or you stop it halfway through, the default program that does the copying on Windows (explorer.exe) does not support resuming it; you have to start again from scratch.

So it deletes the failed attempt?

Honestly, computers are finicky mate - basically, the system will do what it can to avoid having a fatal problem. If it can't do that, it tries to take the next least destructive option for avoiding a problem. This is really quite rare anyway.

Do you have some examples of least destructive options?

As for that other post you quoted, he's just saying that the thing holding up the USB being removed is typically some other program or window you've forgotten was open.

And for sure not the copying still running?

As I said before, if the USB is really not being compliant, just hit log off on your system. This will terminate any running programs that would be holding the USB hostage and so you can be guaranteed a safe removal at that point in time.

I have not thought about that, out of fear of messing up the copying

I'll be totally frank - it's rare I use the "remove USB" option, and I haven't once encountered issues for it in the time I've used a computer. This of course comes with the caveat that things can go wrong, so if it's super important it's best not to jeopardize it that way.

It is good to hear, that you have done that plenty of times and not encountered any problems!

Again, thank you for taking time to explain and educate

 

[canadianvice]

Basically, if something screws up halfway through, or you stop it halfway through, the default program that does the copying on Windows (explorer.exe) does not support resuming it; you have to start again from scratch.

So it deletes the failed attempt?

Honestly, computers are finicky mate - basically, the system will do what it can to avoid having a fatal problem. If it can't do that, it tries to take the next least destructive option for avoiding a problem. This is really quite rare anyway.

Do you have some examples of least destructive options?

As for that other post you quoted, he's just saying that the thing holding up the USB being removed is typically some other program or window you've forgotten was open.

And for sure not the copying still running?

As I said before, if the USB is really not being compliant, just hit log off on your system. This will terminate any running programs that would be holding the USB hostage and so you can be guaranteed a safe removal at that point in time.

I have not thought about that, out of fear of messing up the copying

I'll be totally frank - it's rare I use the "remove USB" option, and I haven't once encountered issues for it in the time I've used a computer. This of course comes with the caveat that things can go wrong, so if it's super important it's best not to jeopardize it that way.

It is good to hear, that you have done that plenty of times and not encountered any problems!

Again, thank you for taking time to explain and educate

1. I guess you could say that. At this point, it really doesn't matter, does it? Basically, it's out of sight, out of mind, you need to restart making a copy if there was an issue.

2. No, my point is simply that this is usually how code works, and Windows is no exception. Again, these problems you're concerned with are exceedingly rare, to the point I've never directly experienced it.

3. Well, if it is still running, that'd be it. For the most part though, you'd know. Worst case scenario, when you go to log off, I imagine Windows will complain that there's something going on and you'll be afforded the chance to abort logging out if it's important. You kind of have to feel this stuff out. Generally speaking, if you don't clearly know what's holding the USB hostage, it's probably not important if you log off and it is force closed.

Really, if getting a valid copy on to a USB stick is so important, you're best to try using a program like TeraCopy to do it - there's a very clear GUI and it has an option to validate the file (check that it's what it should be) once the copying is done.

By and large I have to emphasize that barring something like pulling the USB out in the middle of a copy (like, deliberately causing a problem with the process) you see going on screen, there's not a lot that will generally screw this process up.