If you’re relying on a backup or migration strategy that involves mass-copying files to network drives using Windows Explorer, here are two tips that will probably save you some frustration:
When moving a folder that contains deeply-nested folders, you may well encounter illogical errors about a file name being too long. The file name itself is clearly not the problem; a typical error message is words to the effect, “Cannot copy file foo.bar. File name is too long.” The true problem is that the path to that file is too long — specifically, longer than 255 characters (or 256, depending on where you read about it). Amazingly, parts of Windows still have this limit wired in, and one of those parts is Windows Explorer. Various applications can make successful system calls to store files in deeply nested folders with very long paths, but Explorer will choke on them in simple drag-and-drop operations.
The only solution I’ve been able to find is go to the source machine, map a network drive letter to some point farther down the directory tree on the target machine, and copy to the network drive. Fortunately, this often works adequately … for example, in my case I was copying to the following target folder:
\dev\c\Documents and Settings\Bob\Application Data\Thunderbird\Profiles
That folder contains all my Thunderbird mailboxes, amongst other things, to several more folder levels of depth. Mapping the above to drive Z: and copying to Z:\ shortened the effective path enough to allow all the files to go without complaining.
The second problem I encountered in moving some files between machines was the illogical message, “Cannot find file thumbs.db. Make sure the file exists and try again.” Thumbs.db is a hidden OS file created in any folder where you have ever used the thumbnail view in Explorer. What’s happening is that when you select a group of folders to copy, Explorer includes thumbs.db in the list of files to move, but when enumerating those files to actually copy them (at least across a network boundary) it can’t see thumbs.db in the enumeration.
My solution was to go to Tools | Options | View in Explorer on the source machine and make sure that “Do not cache thumbnails” is checked; that “Show hidden files and folders” is selected; and that “Hide extensions for known file types” is unchecked. Then click “Apply to all Folders”. Lastly, go through your source directory tree on the source machine and remove all instances of Thumbs.db. Now you can do your copy, and, if desired, put the folder options back to your true preferences on the source machine.
These two problems are examples of why backup software exists, I guess. But lots of people these days are saving at least some of their data on virtual drives in the cloud or on NAS devices, portable USB drives and the like. And then there’s the matter of migrating data to new homes, as I’m doing. At times, you might reasonably think it’d be much simpler to just copy data files than to perform backups and restores. But in some cases, at least, you’d be wrong.
{ 2 comments… read them below or add one }
Have you tried rsync? Instructions for use on Windows here.
I’ve only tried it between Mac and Unix machines. Extremely fast and accurate.
Bob responds: Thanks, but I’m a little wary of a site that starts out with the comment, “The rsync provided here is very old. There are many known bugs, and some of these may cause data corruption.” After all, I already have known bugs with Windows Explorer, but as far as I know, no data corruption. If you don’t mind rsync’s Cygwin baggage, one of the other links on that page to more recent updates / re-packagings of rsync might be worth looking into, though.
Cygwin has the same path length problem as Windows, so rsync probably won’t be able to help.
Funnily enough, some years ago I was experimenting with the SCM tool ‘arch’, which creates very long paths which made it unusable in Windows. One approach that was being investigated in the arch community was to exploit an interesting feature in Windows. Unicode paths can be longer than 256 chars, so if you prepend \?\ to the start of the path then it looks Unicode-ish, and some APIs will work.
The idea was to add a thunking layer to Cygwin which would intercept long paths, and use the Unicode paths instead.
I did some investigation myself, and did indeed get some of it to work. There were a few APIs that still didn’t support the Unicode hack, but there was usually a way around it.
In the end, MS released Services For Unix, which did work correctly with long paths.