Os x copy large number of files

The mkdir is because the entire folder and everything within it would be moved into the other directory and no longer exist in the old directory. It ensures that the old directory still exists. However, this wouldn't be sufficient if there was a service constantly running that depended on the first directory always existing, because it is moved and then recreated.

It doesn't make anything faster, just simpler by providing less arguments. Just for variety, I'm fond of using cpio for some cases like this. Arthur Ulfeldt Arthur Ulfeldt 1, 10 10 silver badges 13 13 bronze badges. If the source and destination are on the same file system then this approach could be very inefficient unnecessary copying.

Also it is always better to use -print0 and -0 options. With GNU mv : find. Lri Lri 4, 1 1 gold badge 24 24 silver badges 19 19 bronze badges.

For a specified time try the following: find. Sign up or log in Sign up using Google. Sign up using Facebook. Sign up using Email and Password. Post as a guest Name. Email Required, but never shown. The Overflow Blog. Stack Gives Back Safety in numbers: crowdsourcing data on nefarious IP addresses. Featured on Meta. New post summary designs on greatest hits now, everywhere else eventually. Related 9. Hot Network Questions. Sometimes, it takes more than double the time indicated to recharge.

I changed the menu bar display to indicate the percentage, and it is more useful. It is sad that a big company like Apple cannot predict the time to complete such a simple task with more accuracy. And Pierre, maybe Apple compares the copying of thousands of files to a fireworks display : it takes more time to prepare the explosives than it does to explode in the sky!

Yeah, but at least fireworks are spectacular. There is definitely nothing spectacular about the copying process itself! Most of the time, when dealing with smaller numbers of files and often transferring them from disk to disk, the preparation phase is momentary and the actual file operation takes a while. Even when dealing with thousands of files, like your original copy operation, the preparation undoubtedly took a couple of minutes, but most of the operation time took place during the copy, which had a progress meter.

The indeterminate progress meter is far more useful than no indication at all or a beachball , and I consider it progress while still hoping The good news is that while DOS also choked on thousands of files, Unix command line interfaces handle them with aplomb, including OS X. Equipment makers have to build in all types of estimations about how the batteries are accepting and will accept charge, and they can vary based on temperature, age and usage profile of the battery, and many other factors.

The copy itself with the progress meter only lasted a fraction of a second! I suspect that the only reason that Apple feels the need to show the user two distinct phases preparation and action is because they are unable or unwilling to better estimate the time required for the preparation, whereas they believe that they are better able to estimate the time required for the action itself, which has a progress bar.

However this particular case seems to show that the distinction between the two phases does not actually correspond to two very distinct stages in the process. And in fact my experience in Mac OS X It often looks like the switch from one phase to the other in the progress window is out of sync with the actual process. The example above is an extreme case.

But this apparent lack of synchronization seems to have become more prevalent in Mac OS X I understand your frustration. However, I try to schedule my intensive file copying for times when I can drag the items to the new location and do something else and leave my computer alone for the time it takes to copy. The disadvantage of this is that you cannot schedule every copying task this way.

Like danridley said, we can always hope Luckily, I can deactivate this time estimating feature as I did and it is not always staring at me. Thank you for the insight on this matter. Back when I was a Windows user, in Windows 95, Explorer could gracefully handle up to a couple of hundred files; the command prompt would gracefully handle a thousand or so.

Both of those figures are orders of magnitude better on OS X and both remain better on OS X than on Vista , and both will continue to get better as both the OSes and the hardware improve. But the gap between command line and GUI remains. Finder checks permissions, free disk space, open files, etc. If this leaves you with a half-moved folder, it lets you clean up; Finder attempts to pick up after itself. Not always successfully, of course. I need to be able to copy about 2TB of data from an external drive single USB external disk to a another external drive Drobo attached via Firewire.

Finder is not an option. If it hits any problem, it stops the process and I have to figure it out why it failed and start over. It could take me months to get through it. You can prepare the command and perform a dry-run before committing to the copy; add --dry-run to simulate the copy. This also allows rsync to write the files to the new drive recreating the original owner information.

There are numerous guides for getting the most from rsync , rsync command examples provides relevant examples. Take care with the trailing slashes; these can make a world of difference if your copy starts with a folder.

Alternative tools include ditto and cp. Both are reasonable choices but offer differing syntax. I answered a similar question here a while back. My answer is copied below. The "fastest" way would be to physically move both drives to be internal to a single computer, do the copy or rsync , and then move them back. I'd still use rsync, because if interrupted for any reason cat steps on the power switch? It also won't copy any files that are the same and in the same place. If you don't want to go the command line route, I use the FreeFileSync app routinely to sync 2 TB of data from an external array to a network location without issue.

You can control how it handles errors and get a log when its complete. We will be using Disk Utility's restore function. Some background on the different between Restoring vs copy and pasting:. The Restore function in Disk Utility makes use of a block copy function that can speed up the copy process. It also makes an almost exact copy of the source device. When we say "almost exact," we don't mean to imply that useful data may get left behind, because that's not the case.

What it means is that a block copy copies everything in a data block from one device to the other. The results are almost an exact copy of the original. A file copy, on the other hand, copies data file by file, and while the file data remains the same, the location of the file on the source and destination devices will likely be very different. Using a block copy is faster , but it does have some limits that affect when it can be used, the most important being that copying block by block requires that both the source and destination devices be first unmounted from your Mac.

This ensures that block data doesn't change during the copy process. But it does mean that neither the source nor the destination can be in use when you use the Restore capabilities. Before you restore a volume, copy any files on the destination volume that you want to save to a different volume. Sign up to join this community. The best answers are voted up and rise to the top.

Stack Overflow for Teams — Collaborate and share knowledge with a private group. Create a free Team What is Teams? Learn more. Fastest and safest way to copy massive data from one external drive to another Ask Question. Asked 8 years ago. Active 1 year, 7 months ago.