I ran into an interesting problem recently, which I only resolved today though a bit of trickery.

With the release of OneDrive, Microsoft replaced the existing SkyDrive application on OS X with a new binary. It still refers to the same ~/SkyDrive folder on the file system, but it’s definitely different.

One of the major ways I found this out is how it handles symbolic links (spoiler: it doesn’t).

Because I have (unfortunate) experience with backups, I use several cloud storage vendors, including Dropbox and SkyDriveOneDrive.

I don’t have unlimited disk space though, so I use symbolic links on OS X, and directory junctions on Windows, to map certain folders to these different vendor paths, to avoid duplication and have multiple backups of the same data.

With the new version of OneDrive, symbolic links don’t get followed. Instead, for a sample directory size of 5GB, your CPU goes mad, I/O on your hard drive goes mad, because it’s writing this to the log file all the time:

03-25-2014 17:03:11.769 - fileSystem.cpp:200!openFileRead (ERROR): openFileRead /Users/myUserAccount/SkyDrive/Desktop/filename failed. errno: 1
03-25-2014 17:03:11.769 - localChanges.cpp:1729!startLocalChangeHash (DETAIL): Opening hash handle -1 for file '/Users/myUserAccount/SkyDrive/Desktop/filename'
03-25-2014 17:03:11.769 - localChanges.cpp:1733!startLocalChangeHash (NORMAL): openFileRead failed on /Users/myUserAccount/SkyDrive/Desktop/filename, err 1
03-25-2014 17:03:11.769 - localChanges.cpp:2274!handleLocalReplaceFile (ERROR): Transient Error (REPLACE_FILE_COULD_NOT_OPEN): postponing replace file'C30E03CFF2436B47!44000' because the file could not be opened; ignoreMissingFile=TRUE. Attempt 1

So I decided to try out hard links instead. Using the following source, I created the following C program, and compiled it, from the accepted answer:

#include <unistd.h>
#include <stdio.h>

int main(int argc, char* argv[]) {
 if (argc != 3) {
  fprintf(stderr,"Use: hlink <src_dir> <target_dir>\n");
  return 1;
 int ret = link(argv[1],argv[2]);
 if (ret != 0)
 return ret;

Take into account that the hard linked directories may not be in the same parent directory, so you can do this:

$ gcc hlink.c -o hlink
$ mkdir child1
$ mkdir parent
$ ./hlink child1 parent/clone2

So there you have it. Creating the hard links fixed it immediately. When OneDrive was restarted, it saw the folders as real (because they are), and synchronised everything almost immediately.