jessegrosjean/dropboxsync

Dropbox to iOS sync

DropboxSync is designed to keep a local folder hierarchy on iOS synced with a Dropbox folder hierarchy. The goal is to work like Dropbox on other platforms… ie the client application works with files on the file system, and they are magically synced in the background.

Operation

Unfortunately DropboxSync can't be quite as magic from an application developers perspective as Dropbox on the Desktop. In particular you are responsible for controlling the sync process through calls to enqueueFolderSyncPathRequest after you've made local changes to files in a directory, or when you want to refresh a directory from the server.

PathController maintains state on synced paths and fires notifications when those paths are modified as part of the sync process. PathController also provides a set of "Path Modifications" methods that fire those same events. The idea is that you can use those method when making your local filesystem notifications, and then your views can get a universal set of file changed notifications no matter if it's your code, or the sync code that's updating the paths.

Requirements

DropboxSync uses a slightly (DBRestClient>didParseMetadata) modified version of the Dropbox SDK that fixes a bug with wifi hotspot paywall pages.

DropboxSync uses Coredata to store local metadata used by the sync process.

Limitations

DropboxSync doesn't handle local renaming of synced folders well. Renames are synced as Delete/Add on server. For files this works, but for directories there are no checks on place to see if server directories contents have been modified, and so a local rename will just delete those files. I just disable local folder rename in my app, a better solution would be to make to the Dropboxe API Rename command.

Running Tests

Before running tests you must set your application keys and dropbox password in PathControllerTests.h. You also need to copy the DropboxTestFolderFixture (in Tests) to you Dropbox account and then update PathControllerTests.h with that path.

Basic usage

// 1. Set Dropbox shared session with keys from app using API
[DBSession setSharedSession:[[[DBSession alloc] initWithConsumerKey:CONSUMERKEY consumerSecret:CONSUMERSECRET] autorelease]];

// 2. Create path controller.
PathController *pathController = [[PathController alloc] initWithLocalRoot:LOCAL_ROOT serverRoot:SERVER_ROOT pathMetadataStorePath:METADATA_STORE];

// 3. If isn't already linked then link
if (!pathController.isLinked) {
	[pathController linkWithEmail:DROPBOX_ACCOUNT password:DROPBOX_PASSWORD];
}

// 4. Sync top level (not recursive) local root with server root.
[pathController enqueueFolderSyncPathRequest:pathController.localRoot];

dropboxsync's Issues

FolderSyncPathOperation.m:202 doesn't compile

Looks like its trying to call a getter of normalizedDropboxPath on an NSString. I also see a lot of warnings along the same lines. What is the intent of normalizedDropboxPath?

Can't Cancel Sync in Progress if Dropbox Unreachable

Hi Jesse,

Found this one in the course of "pull the cable" testing.

If Dropbox is unreachable when you start a sync, FolderSyncPathOperation can't load metadata. The db client will eventually time out (~ 2 minutes, I think), but you can't cancel the sync before that time with cancelSyncInProgress because:

• cancelSyncInProgress calls [folderSyncPathOperationOperationQueue cancelAllOperations]
• -[FolderSyncPathOperation cancel] calls -[PathOperation cancel]
• -[PathOperation cancel] simply returns without canceling if self.isExecuting is YES.
• The only way self.isExecuting is NO is if a path operation calls finish:
• Since the metadata isn't loaded yet, there are no path operations (except for the FolderSyncOperation) to call finish: so the cancel never completes.

I'm not sure why self.isExecuting is blocking the cancel (I suspect there are some path operations that need to complete), so I've worked around this specific case by setting isExecuting to NO in -[FolderSyncPathOperation cancel] as follows:

- (void)cancel {
    if (![NSThread isMainThread]) {
        [self performSelectorOnMainThread:@selector(cancel) withObject:nil waitUntilDone:NO];
        return;
    }

    [[[pathOperations copy] autorelease] makeObjectsPerformSelector:@selector(cancel)];
    needsCleanupSync = NO;
    updatedLastSyncHashOnFinish = NO;

    if (!loadedMetadata) {
        if (pathOperations.count == 0) {
            [self willChangeValueForKey:@"isExecuting"];
            isExecuting = NO;
            [self didChangeValueForKey:@"isExecuting"];
        }
        [super cancel];
    }
}

Since there are no path operations, the only thing to cancel is the metadata request, which will now be cancelled in [super cancel].

I reproduce this by disconnecting my wireless router from the cable modem.

-Steve

GetPathOperation always flags a conflict if server copy is modified.

When downloading a modified server version, [GetPathOperation restClient:loadedFile:] doesn't consider that the local copy (localExists == YES) may not have changed. The following code always moves the local copy aside, renaming it with a conflict name.

NSData *localData = [NSData dataWithContentsOfMappedFile:localPath];
NSData *downloadedData = [NSData dataWithContentsOfMappedFile:tempDownloadPath];

if (![localData isEqualToData:downloadedData]) {
    /* handle conflict */
}

You could fix it with something like:

NSDictionary *localAttrs = [fileManager attributesOfItemAtPath:localPath error:nil];
NSDate *localModifiedDate = [localAttrs valueForKey:NSFileModificationDate];

if (localModifiedDate == nil || ![localModifiedDate isEqualToDate:localMetadata.lastSyncDate]) {                
    /* handle conflict */
}

Or by handling conflicts at a higher level.

README should mention CoreData.framework is required

shadow without lastSyncDate that isn't in error state

Hi Guys,

Thanks for open sourcing DropboxSync, it has been great to use so far, except for a few issues. This is the first one:

I am using DropboxSync in an iPhone app to sync one directory of text files and one of our beta testers keeps on getting a crash with the error: "NSInternalInconsistencyException: shadow without lastSyncDate that isn't in error state".

This error seems to be coming from this NSAsset here: https://github.com/jessegrosjean/DropboxSync/blob/master/Source/FolderSyncPathOperation.m#L145

I can't figure out why this is happening and the only way I reproduce this locally is edit the PathMetadata.sqlite database manually and set one of the files lastSyncDate to NULL.

Do you have any idea why this might be happening and how I could work around this issue in my app?

Cheers,
Isaac

Race condition in scheduleFolderSyncOperations

I believe there are some race conditions in [FolderSyncPathOperation scheduleFolderSyncOperations]. If both the local copy and the server copy of a file is modified, operations on the path will be in more than one operation queue (Delete, Get, Put). The NSOperations in these queues are concurrent, and you don't have any guarantees on which will complete first.

For example, foo.txt is modified locally and on the server, the scheduleFolderSyncOperations method will put a GetPathOperation on the getOperationQueue and a PutPathOperation on the putOperationQueue.

If the "get" operation finishes before the "put" operation starts, the local mods will be moved aside and replaced by the server mods. When the "put" operation starts, it will push the just-downloaded changes up to the server instead of the local changes.

One solution would be to modify scheduleFolderSyncOperations so that the conflicts are handle separately.

PathController shouldn't retain its delegate

By convention, controllers don't retain their delegates. The delegate property of PathController

@property(nonatomic, retain) id <PathControllerDelegate> delegate;

should probably be

@property(nonatomic, assign) id <PathControllerDelegate> delegate;

and the [delegate release] in -[PathController dealloc] should be removed.

Conflict when relaunch application

Hi,

I find that the syncing always give conflict when relaunching the application.

Debugging the code shows that serverMetadata.lastModifiedDate is always the running time of the application and not the modified date from the server file.

Hence the iphone copy always have the modified date as when it is last synced, and the server copy is the original modified date, hence a conflict is created.

Help?