I mean, Windows 7, Ubuntu 9.10 and Snow Leopard... All newest and top of line desktop operating system still use regular copy to transfer files, as it seems to me from experience.

Instead of using some technique like rsync, sftp, or whatever is used to backup time machine, when you want to copy a file over network, or large amount of data through USB, or even to a really big pen drive, you have the eminent risk of having to start all over again, if you want convenience of course.

So, why they insist on going like that?

link|improve this question
3  
Well KDE4 partially does resumes - you can pause it, but unfortunately if you copy it again, it can't resume from where the transfer got cut off. – Sathya Feb 17 '10 at 21:34
1  
At least that shows somewhere someone who can do something about it is actually trying to. :) – Cawas Feb 17 '10 at 23:18
Hey, cool, this became "community wiki". Diago, mind telling me why? This is new to me! :) And also curious on what would happen, from the system point of view, if I "started a bounty". I won't. I have no reason to. Just want to know. – Cawas Feb 20 '10 at 0:24
1  
@Cawas: Diago made this CW at Feb 18 at 3:04. I would guess he did so because there's no "right" answer. You're asking something that's more of a discussion, which means it should be Community Wiki. You can still start a bounty to get more answers, but up/downvotes here now have no effect on posters' rep. – Josh Feb 23 '10 at 14:45
@Josh Yeah, I agree. Thanks to you both @Diago - This have no right answer indeed, but I'll mark one if it's good enough - No guesses nor advices on what to do instead. I was clearly not asking about alternatives. I wanted to know if there's an underlining technical issue that's so hard to overcome, or if it's just about politics and economics. – Cawas Feb 23 '10 at 19:44
show 1 more comment
feedback

4 Answers

up vote 4 down vote accepted

At least for Windows there is a remedy, one of the reasons i'm using TeraCopy: it can resume broken file transfers.

link|improve this answer
1  
That's the best answer so far, from my point of view... But it's really off topic! :P – Cawas Feb 20 '10 at 0:28
feedback

Probably because there are downsides to those like lots of I/O operations and a performance hit.

A straight copy is probably better off performance, I/O, and system wise.

link|improve this answer
2  
Really? I don't agree. What if I'm coping a 4.7 GB DVD image to a network share and 75% of the way through I lose my net connection? Wouldn't it be much faster to just copy the remaining 25%? – Josh Feb 17 '10 at 3:22
6  
@Josh: I'll give you long odd that (for "users" rather than for people whose job is computers) most copies are small files; that most operation occur between locally mounted, reliable devices; and that those small, local moves total more than half the bytes copied. So the protection for big copies is not worth the extra overhead on the bulk of operations. As a stopgap you can use a more sophisticated method for you big, vulnerable copies. – dmckee Feb 17 '10 at 3:37
@dmckee: A good explanation, thanks. – Josh Feb 17 '10 at 3:41
There are downsides, but c'mon, systems nowadays can learn and be smarter than this. – Cawas Feb 17 '10 at 3:49
I'm not arguing that yes it would be faster in that case, I'm saying in the long run the vast majority of copies benefit from a straight copy. – Josh K Feb 17 '10 at 13:35
show 6 more comments
feedback

I am just guessing here... but I suspect it's because of non Super Users. For a less skilled computer user, it might be confusing if they received a prompt stating "This file already exists, do you want to: [Cancel] [Overwrite] [Append]". Keep in mind that often the proper action is replacing, people will be coping a newer version of a document to a USB drive to update the drive, or doing a backup, and thus wanting to overwrite the previous version with the new version.

Just a few thoughts... not being an OS developer I can't say for sure ;-)

link|improve this answer
I don't think there are many OS developers out there. ;) Windows is already too confusing for most less skilled users - I think there should just be a way to at least enable such a feature. – Cawas Feb 17 '10 at 3:48
One suggestion would be to introduce the file hash to the header. Then, the OS can compare both, and if found to be identical, prompt the user to resume copying. For files with different hashes but same name, the traditional "Overwrite/Cancel?" dialog can be used. Of course, file hash can be cumbersome to generate for very large files. – syockit Mar 5 '11 at 15:05
feedback

If you are transferring large files over an unreliable network, use rsync with the --partial option. Your use case is rather rare. The share on one system I use has a transfer that takes over a day, with no threat of lost data due to an incomplete transfer (it is slow for some reason to look into, sometime).

Edit: @Cawas: the more common use case is copying over a file with a new version of the file. If a file has been modified (made bigger in this case), trying to append the extra length of the new file to the old file will result in a corrupt file. Protocols like rsync and ftp can assume you are not doing this.

link|improve this answer
That's cool. I'm just bothered on why options for file transferring breaking isn't default on OS - even if just for specific transfer operations. Or at very least it could give an option to enable "resuming" every time it identifies the transfer is big enough to break. – Cawas Feb 17 '10 at 3:47
feedback

Your Answer

 
or
required, but never shown

Not the answer you're looking for? Browse other questions tagged or ask your own question.