Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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?

edit: since this still got no answer even today, I'm bringing it to most relevant discourse site I could find: http://discuss.howtogeek.com/t/why-every-os-still-cant-resume-file-transferring/16832

share|improve this question

closed as primarily opinion-based by Ƭᴇcʜιᴇ007, Zoredache, Tog, Kevin Panko, harrymc Jun 18 at 8:40

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

4  
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

5 Answers 5

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.

share|improve this answer
3  
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
8  
@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

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 ;-)

share|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

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.

share|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

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

share|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
    
Thinking again, I shouldn't accept an answer just due to lack of better ones. ;) –  Cawas Jun 19 at 21:40

The reason why this feature has never been implemented is right here in front of your eyes. You just need to read through the comments to see that it is an extremely unpopular feature.

Add the overhead required for such operation, and there you have your answer: it is not going to be implemented as a default feature on any major OS anytime soon.

share|improve this answer
    
Thanks for resurrecting this! ;-) I don't know, that seems all pretty reasonable but unsustained. How much overhead is there, really? Popularity is not exactly a matter here, especially for non-windows. –  Cawas Jun 17 at 16:52
    
Popularity DOES matter. At least between the programmers that are supposed to develop the feature. With the right rationale it is feasible. Eg apply only for files larger than "x", when the transfer is slower than "y", or when the extimated transfer time is more than "z". And keep the partial files for a maximum of "J". But it still sounds like a very specific feature, not likely to be developed/implemented. –  Bruno9779 Jun 17 at 16:59
    
Popularity does matter at least between the programmers - that I agree. I don't think it's that unpopular among programmers, it's just most of them who are not satisfied with it at least know about rsync. And I bet most would appreciate it if we could have it built in the system. You still talk as if the overhead was huge... We have so many interpreted languages nowadays which have some "overhead" over C, but they still exist. I don't think there is a significant overhead in having this implemented... Maybe just in implementing it and updating it. –  Cawas Jun 19 at 21:44

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