Is it normal that this should take so long?

[futurefields]

I had about 13gb of music on my C drive that i wanted to move to my D drive.

Both are Western Digital 7200RPM the C drive is 500gb and the D drive is 3tb and they are both on SATA3.

I cut and pasted the folder and it took several minutes (want to say between 3 and 5) for them to move. Is it normal it should take that long?

 

[MongGrel]

yes

 

[corkyg]

Why do you consider that a long time? Seems perfectly normal. It may have been faster to drag and drop rather than cut and paste - that involves the clipboard.

 

[nerp]

Seems normal. Keep in mind that read/write speeds won't always max out when dealing with small files. Huge files you will see majorly good speeds sustained for some time. But small files will slow things down a bit.

 

[ronbo613]

I've noticed that copying(or cutting) and pasting large numbers of various size files takes the longest time.

 

[IronWing]

It may have been faster to drag and drop rather than cut and paste - that involves the clipboard.

No kidding? I didn't know that. I always cut and paste because I'm a keyboard shortcut fan.

 

[Charlie98]

It may have been faster to drag and drop rather than cut and paste...

:thumbsup: +1

In any event, ~5 minutes or so isn't unusual.

 

[tortillasoup]

Why do you consider that a long time? Seems perfectly normal. It may have been faster to drag and drop rather than cut and paste - that involves the clipboard.

Files don't involve the clipboard at all. Drag and drop would have no performance improvement over cut and paste.

 

[pcgeek11]

I never Cut and Paste as if it screws up half way through there is a very good chance of data loss.

Copy and paste to a different location. After I verify the copy is good I will delete the source files if desired.

 

[corkyg]

Files don't involve the clipboard at all. Drag and drop would have no performance improvement over cut and paste.

Not in my world. Cut places the target on the clipboard. It stays there until paste moves it from clipboard (memory) to desired location. Basically, cutting and pasting is not intended for moving files. To really be safe using that technique, copy and paste would be better because if you goofed, the original file is still untouched. If you cut, and then lose power and reboot, you will have lost the file completely. Why? Because it was sitting in volatile memory - also called the clipboard.

 

[tortillasoup]

Not in my world. Cut places the target on the clipboard. It stays there until paste moves it from clipboard (memory) to desired location. Basically, cutting and pasting is not intended for moving files. To really be safe using that technique, copy and paste would be better because if you goofed, the original file is still untouched. If you cut, and then lose power and reboot, you will have lost the file completely. Why? Because it was sitting in volatile memory - also called the clipboard.

You can't place 2GB+ worth of "files" in the clipboard because if so, then the action of hitting Cntrl + X would take a few minutes to perform. It never happens that way, ever.

 

[JimmiG]

"Cutting" a file just marks it for moving. It doesn't actually touch the file. The process isn't initiated until you "paste" it somewhere. Cut/Copy and Paste are just UI metaphors.

When moving files (via Ctrl+X - Ctrl + V, drag and drop, or any other method), the file is first copied, then the original file is deleted. If you cut the power while a file is being "moved", the original file will remain. Actually moving the file bit for bit would be inefficient and less reliable.

 

[nerp]

Clipboard not involved in file cut/paste. All you're doing is triggering the exact same function as drag/drop. Windows offers 20 ways to do one thing. Just like dragging a USB drive to the trash bin doesn't delete it on OSX. It simply ejects. The act doesn't always literally translate.

 

[pcgeek11]

Oh but the clipboard is involved in both operations Cut and paste and copy and paste.

It uses the clipboard to hold the location of the files that are being cut and pasted. If something happens during the cut and paste that locked the pc and a hard reboot is required the locations can be lost. Therefore the file itself is also lost.

It does in fact happen.

A copy and paste also does the same but the original file is not touched and will remain intact in the event of a reboot.

 

[JimmiG]

It's true that the clipboard holds a list of the files to be copied/moved. This is the only thing that would be lost during a power outage. Meaning that once your PC powers on again, you would have to select the files again and press CTRL+X. However CTRL+X doesn't touch the files or the file table. It's *exactly* the same as using drag and drop.

 

[pcgeek11]

I'll just say we disagree.... and leave it at that. I know what I have seen happen.

I'll stick to my proven method of copy and paste.

 

[repoman0]

Oh but the clipboard is involved in both operations Cut and paste and copy and paste.

It uses the clipboard to hold the location of the files that are being cut and pasted. If something happens during the cut and paste that locked the pc and a hard reboot is required the locations can be lost. Therefore the file itself is also lost.

Why would losing temporary file locations marked for copy, stored in RAM, affect the file system at all? At any given time your PC is accessing who knows how many files, are you saying that if you hard reboot those files will magically disappear too just because the file locations exist somewhere in memory? Windows/UNIX are both smarter than that.

Cut and paste is just a copy operation with a built in delete upon successful copy completion. If the copy never completes due to a reboot, the delete never initiates.

If it's a really critical copy operation, compute a checksum on both collections of files and make sure they match before deleting the old ones. I am not sure how much verification Windows or UNIX does by default before it deletes the old files.

 

[pcgeek11]

What I said was it Can be lost. I have seen it happen.

 

[VirtualLarry]

What I said was it Can be lost. I have seen it happen.

I have too. don't Cut and Paste, Copy and Paste, Verify, then Delete.

 

[JimmiG]

What I said was it Can be lost. I have seen it happen.

If it's a really critical copy operation, compute a checksum on both collections of files and make sure they match before deleting the old ones. I am not sure how much verification Windows or UNIX does by default before it deletes the old files.

If you want to be almost certain that the copy operation was successful, that would be the way. A regular copy+manual delete or "move" (copy+automatic delete) operation wouldn't do an actual compare like that.

 

[ClockHound]

I just use xplorer2 or terracopy and let them deal with the copy/move/overwrite/verification overhead.

Only use Winduhs Explorer for anything when I haven't reached my daily quota of irritation.

 

[destrekor]

What I said was it Can be lost. I have seen it happen.

IF something were to be lost, it is only the file system's pointer, not the bits. Any HDD recovery tool should be able to recover those files.

That is, so long as the system went down immediately after or during the file operation. With time, the risk of data loss increases as the HDD and FS acknowledge those sectors are now free.

 

[tortillasoup]

IF something were to be lost, it is only the file system's pointer, not the bits. Any HDD recovery tool should be able to recover those files.

That is, so long as the system went down immediately after or during the file operation. With time, the risk of data loss increases as the HDD and FS acknowledge those sectors are now free.

how does one recover files if the pointers are missing and the files are fragmented?

 

[destrekor]

how does one recover files if the pointers are missing and the files are fragmented?

:hmm: good point

 

[dave_the_nerd]

13 GB = 13000MB. 5 minutes = 300 seconds. 3 minutes = 180 seconds.

43-72 MB/sec? Not bad. Probably close the max speed of the 500GB drive. Especially good if the computer was doing other things at the time or if the data was fragmented.

In terms of files copied per second (somewhere between 8 and 14) it's actually pretty good. (File systems add overhead to every transaction, which can be especially painful if you're copying lots of really small files, like source code or something. Although in this case I don't think that was your bottleneck.)