Copying one folder over another of the same name destroys data!

[technologist]

I like the idea of a real Undo for filesystem operations. The only risk is with huge folders; keeping a backup available on disk might not be practical.

(I don't much like the idea of re-creating the replaced folder in the Trash, though. If there are already items in the Trash, the user might not notice the backup before emptying it.)

http://www.apple.com/macosx/feedback/

 

[torchy]

Does anyone actually empty the Trash without checking what's in there first?

 

[Cloudane]

To be honest I doubt they read the feedback, but perhaps this is just due to bad experience from less reputable companies. I'm happy to give it a try, though.

Here's the first draft - my opinion stands as it is, but suggestions are welcomed and appreciated in terms of making the feedback clear, making it sensible, getting their attention, avoiding them dismissing the issue etc etc. And I'm a Mac user, I'm on YOUR side - anything which you feel could harm more... "normal" Mac users, please let me know. I've tried to keep the suggestions as low-impact as possible.

TITLE: Switchers at risk of **losing files** - Replacing one folder with another works differently in Windows

What I am about to mention is, *technically*, not your problem. However, in terms of your Switch campaign, and making the switch from Windows as comfortable as possible, it may be in your interest especially because the issue at hand can put switcher's data at risk.

The problem & background
------------------------

Copying one folder on top of another in Windows causes it to merge the contents of the new folder with the contents of the old one, overwriting any files which have the same name, but keeping all the existing files. It does this for every single subfolder and sub-subfolder etc it comes across too. (This may not be the most logical method, but it is quite safe because it avoids deleting a user's data - which should be treated as sacred.)

Copying one folder on top of another in OS X, however (and telling it to replace it), causes it to DELETE the old folder and ALL its subfolders - the entire tree - before replacing it with a copy of the new one. Any files in the 'old version' of the folder are gone forever - they do not even go to the trash. This is the most logical result given the dictionary definition of the word "replace" - but also the most dangerous, at least to switchers.

Illustration / example
----------------------
Let's say I have disk A from computer A which runs Windows. Disk A contains a backup of the "My Documents" folder. That folder contains a bunch of documents as well as "My Pictures", "My Music" etc.

Now I have disk B from computer B. That has the same thing - a bunch of files and folders along with My Documents and its subfolders.

I want to copy the contents of disk B onto disk A so that the My Documents folder on disk A will contain its existing documents as well as those from disk B. I want the same thing to happen with its subdirectories so that My Documents\My Pictures contains the pictures that were already on disk A as well as those copied across from disk B.

Windows users, at a certain knowledge level, know that this procedure is very easy. You copy My Documents from disk B to disk A and say "Yes to All" when it asks whether to overwrite any files it comes across with the same name on both disks. The two folder structures and contents are now merged into one, with the contents from disk B taking priority over those existing on disk A.

In Mac OS X, if you assume it will act the same as Windows, it will lead to disaster. Copying My Documents and telling it to replace the old one will do just that - it'll delete the old one and you'll end up with essentially two 'disk B's and everything from disk A destroyed.

The only workaround I've found to get the expected behaviour is to open up a terminal and (for example)
cp -rp /Volumes/A/My\ Documents /Volumes/B

However, I digress.

Rationale
---------

To experienced Mac users (with whom I've raised the issue in messageboards), and no doubt to yourselves, this sounds like a "no brainer" and the problem may seem very difficult to understand. However, please do think about it (experienced users of both platforms ought to understand and be able to clarify) because this is a huge stumbling block for some Switchers, who have had the notion of "Replace folder = Merge contents" wrongly engraved into their brains since at least Windows 95. Several other switchers have agreed that they've made the same mistake, often to great cost.

I am not advocating a change to the Windows way, which I admit would be a step backwards in terms of standard human logic, the principle on which Mac OS X thrives. As I'm sure you're aware, such a change would also lead to tens of thousands of irate Mac veterans.

However in line with Human Computer Interaction (HCI) principles, all actions should ideally be reversible whenever it's feasible to provide the option.

Suggestions for tackling the problem
------------------------------------

Following the HCI theory would mean finding some way of automatially putting the replaced folder into the trash rather than deleting it, so the user can restore it later. The idea would pose serious complications when it comes to restoring the folder, but there is no one I trust more when it comes to solving such problems than Apple.

Another possibility would be to update the dialog that pops up when you try to overwrite a folder with a newer one and ask whether you want to "Literally Replace" the folder and all its contents (with a warning that doing so would destroy the old contents), or "Merge and Replace" meaning.. basically what Windows does. Add a tickbox for "Remember my answer" so that the impact on Mac veterans is minimal... the consensus I've received is that users hate being asked "are you sure" too often - a habit which Windows is infamous for.

At the very least, I recommend issuing some sort of warning on your website and/or documentation that the behaviour of replacing one folder with another is not the same as what an ex-Windows switcher would expect.

 

[rman]

Here is what I see. The M$ was was implemented wrong. To me they should have created a merge command. So you would have a copy, replace and merge. In unix you only have to commands cp (copy) and mv (move). Which is causing your problem. I believe what you should be asking Apple is to create a merge option. Since what is happening is what you ask the system to do. You said to replace folder A with another folder A. So the system (unix) removes the old folder A and replaces it with the new folder A, as one would expect it to do.

So what you are asking is along the lines of copy all of the contains of the old folder to the new folder, and replacing only the duplicates. Then you would delete the old folder.

Unfortunately, you have encountered, the ghost of unix.

 

[Kyomii]

I can understand where Cloudane is coming from, and I can see that it would cause potential problems for ex Windows users.

However, the simple solution is, say you are moving a folder named documents, to a folder named documents, is to rename the folder you intend to move to documents_1 and then move it. Same with any files.

I have learnt to do this since having the same problem as Cloudane when I switched.

 

[johnnyluu]

However, the simple solution is, say you are moving a folder named documents, to a folder named documents, is to rename the folder you intend to move to documents_1 and then move it. Same with any files.

Exactly.

Computers do what we tell them to do not what we want them to do.

 

[KuruMonkey]

rman: you aren't quite right in your assertions.

What windows' GUI copy folder with "replace" implements is (in effect)

cp -rf /source_folder/folder_a /dest_folder/folder_a

Which, as you can see, is a "copy" command.

OSX implements (in effect):

rm -dr /destfolder/folder_a
cp -rf /sourcefolder/folder_a /destfolder/folder_a

Notice the extra "delete" command. It does actually do a "if folder /destfolder/folder_a exists" around the delete command, but I don't know enough unix to write that...

 

[rman]

rman: you aren't quite right in your assertions.

What windows' GUI copy folder with "replace" implements is (in effect)

cp -rf /source_folder/folder_a /dest_folder/folder_a

Which, as you can see, is a "copy" command.

OSX implements (in effect):

rm -dr /destfolder/folder_a
cp -rf /sourcefolder/folder_a /destfolder/folder_a

Notice the extra "delete" command. It does actually do a "if folder /destfolder/folder_a exists" around the delete command, but I don't know enough unix to write that...

I don't think there is a -d option for the rm (remove) command. As for unix I believe the command being used is mv (move). The mv command will remove a directory/file and then move the requested directory/file.

 

[KuruMonkey]

I don't think there is a -d option for the rm (remove) command. As for unix I believe the command being used is mv (move). The mv command will remove a directory/file and then move the requested directory/file.

There is a -d for rm; in fact its the first option detailed in the man page.

And we were discussing copy, so mv is hardly appropriate. (mv, being in fact directly analogous to a cp followed by an rm - and cp vs mv having no bearing on whether the existing folder at the target location is deleted; only whether the source directory is deleted after the copy)