Impossible to solve conflicts for Mac "wrapper" type documents

[jdeepwell]

Expected behaviour

After a sync conflict on a Mac client regarding a document that is actually a wrapper the whole wrapper should be duplicated to handle the conflict.

Actual behaviour

Individual files inside the wrapper are duplicated to handle the conflict.

Steps to reproduce

1. Create a document on a Mac client that is stored in a wrapper/package (which actually is a folder) - e.g. in TextEdit create a formatted text with images (file format rtfd).
2. Sync it
3. Make different changes on two Mac clients while offline -> sync conflict

This is a general issue, independent of server & client configuration.

On the Mac many applications use "wrappers" for their document format. These actually are folders but to the user they are presented as single files.

If a sync conflict occurs for such documents, the user not even can recognize the fact that there is a sync conflict, let alone by able to resolve the conflict.

The user would need to look inside the wrapper (which can only be done via a not well known context menu command in Finder, or in the terminal) to even see that there is a conflict.

Inside the wrapper lie several files which the user normally does not see and has no idea what they each are for - some of these will have a conflict dup. The user has no way of knowing which of these files serves what purpose and therefore cannot resolve the conflict(s).

The Mac client can know which documents are actually wrappers and could handle these differently. On a conflict regarding one of the files inside the wrapper folder it should duplicate the whole folder. This though would most likely also require different handling on the server side...

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/37984524-impossible-to-solve-conflicts-for-mac-wrapper-type-documents?utm_campaign=plugin&utm_content=tracker%2F216457&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F216457&utm_medium=issues&utm_source=github).

[hodyroff]

Can you please check what other offerings in the market do for these? (Dropbox, OneDrive, iCloud, Google, etc.)

[phil-davis]

Also, what is the application support for such "wrapper file types" to be able to be opened, understood, displayed (and maybe even edited) on other platforms? (Windows, *nix, iOS, Android)

If the Mac file system can tell an app that the "folder" is actually a "wrapper file type" then it would be possible for the ownCloud client to know this, and then look at the folder date (or whatever information is appropriate) to determine the newer version and initiate a "full sync" of the whole folder structure in the needed direction, and save off a whole copy of the "old" version folder if it sees a conflict situation.

Such types of "files" then need to be marked in the server, so they are then synced to other clients in an "all or nothing fashion". And the server webGUI would need to understand it also for downloading the "file".

If such files are completely useless on any other platform, then it might also be good to blacklist them somehow on those other OS.

[phil-davis]

Note: There may be some joint issues and/or design functionality in common with https://github.com/owncloud/client/issues/5521 because that is also about groups of files in a folder that need to always be kept together as a "synced group".

[jdeepwell]

Thanks for looking into this!

To my knlowedge no non-Apple plattform can make use of Mac documents that are wrappers. iOS might - but on iOS users do not have access to files on that low a level.

As to how other syncing solutions handle this: DropBox cannot. It leads to the usual conflict files within the wrapper - which, as said, cannot be seen by the user. Haven't tried Google and OneDrive.

iCloud of course handles wrappers nicely. If a conflict happens, iCloud will hold separate copies of the whole document wrapper (the whole folder) and present the user with a choice inside the app that handles those documents. Even if you manually create the conflict by changing one of the files inside the wrapper from e.g. the shell on two clients at the same time.

That seems to be basically the sensible approach if one wants to handle macOS wrappers correctly: Sync the whole wrapper or nothing. And if a conflict arises, do not create conflict files for each separate file inside the wrapper but instead create a whole conflict wrapper (keep two copies of the whole folder).

To determine whether a directory is a normal directory or a wrapper, there's an API in macOS:

BOOL isWrapper = [[NSWorkspace sharedWorkspace] isFilePackageAtPath:@"/path/to/directory"]);

The snag I guess is, that this can change any time. It only depends on whether some app registers the name extension a directory is using as a document type. If a dir is e.g. named "SomeDocument.dctype", it can still be a simple folder. Only once some app registers ".dctype" as an extension for its documents, it becomes a wrapper.

[guruz]

FYI https://github.com/owncloud/client/issues/3202