Area:
iCloud / CloudKit

Summary:
Custom extended file attribute is set for files synchronized via iCloud Drive between macOS and iOS. This attribute is lost during synchronization although Apple's "File System Programming Guide" is mentioning all "attributes are copied to iCloud and to the user's other devices too". Using custom attribute "de.stitchbuddy.threads" or "com.apple.ResourceFork" does not make any difference.

Steps to Reproduce:
1. Set extended file attribute "de.stitchbuddy.threads" via setxattr() for a file saved at an iCloud-synched folder on one platform, e.g. macOS; attribute size is less 1 kB. Objective-C code of method attached.
2. Verify the attribute is set via getxattr() in code or xattr in Terminal
3. Wait for the file to by synchronized to the other platform, e.g. iOS (device)
4. Try to read the same attribute via getxattr() in code (same class / method as used on macOS). Objective-C code of method attached.

Expected Results:
The extended attribute exists and has the same value on both platforms.

Actual Results:
The synched file does not have the extended attribute. Reproducible for new or updated files.

Version/Build:
iOS 12.1.4, macOS 10.14.3, iCloud Drive

Configuration:
Two companion apps, using the same class and method to read / write extended attributes; build with Xcode 10.1, macOS SDK 10.14, deployment target 10.10 resp. iOS SDK 12.1, deployment target 9.0.

Comment:
Other developers are observing the same behavior, here is a well-describing article about the problem: eclecticlight.co/2018/01/29/ic…nd-tags-transferred-apps/

So, Apple hat bisher - auch auf Rückfrage im Bug-Reporter und über den Developer Support - keinerlei Stellung zum Problem abgegeben - oder wenigstens weitere Infos angefragt. Der Bug ist noch im Status "Open", wobei dies - inklusive aktualisierter Änderungsdaten - für alle meine Radars gilt, seit Apple zum Monatswechsel Mai / Juni vom Bug-Reporter auf den "Feedback Assistent" umgestellt hat (auch bei eigentlich geschlossenen Bugs, z. B. "Duplicates").

Ich habe meinen Frust im Developer Forum abgeladen und werde nun wohl ein weiteres TSI-Ticket investieren, nur um ein Status-Update zu erhalten. Hoffentlich erstattet Apple es zurück. Leider muss ich abhängig von den Lösungs-Chancen und -Zeiten eine kritische Entscheidung zur weiteren Entwicklung der betroffenen Apps treffen und bin daher nicht wirklich entspannt...

Aber Hauptsache, es gibt einen "Dark Mode" auf iOS ... SCNR

Mattes

So, mal schauen, was nun kommt:

Dear TSI support team,

I filed a TSI (710685235) at March 17th, related to a problem when synching files with extended attributes via iCloud.

You suggested to submit a bug report - what I did (radar 49108839 / FB5702009) - and refunded my TSI credit. Thanks for that!

Unfortunately I didn't receive any news about the reported problem, which is "open" and was not "duplicated", even before the Bugreporter - Feedback Assistent migration this month. I added a comment, asking for some information: No response. I contacted developer support, but they pointed me to you as they couldn't contact the engineering team. So now I'm lost and investing a TSI credit again, hoping you can provide some information:

I have to take some crucial decisions about further app development, depending on the chances and time-frame of the reported problem being fixed. I am pretty sure it is not related to my specific environment, but seems to be a general restriction when synching files which contradicts to the documentation. Other people have noticed the same and I have included related comments and links into my bug report.

So any information you can give about a potential fix is highly appreciated. It is just hard to make decisions without any information...

Thanks for reading, Matthias

Apple's Antwort ist da: Erweiterte Datei-Attribute sollten nicht verwendet werden, um Meta-Daten plattformübergreifend zu speichern, da das Handling je nach Dateisystem / Netzwerkprotokoll zu unterschiedlich ist (Network Shares, USB-Medien). Die zitierte Apple Dokumentation ist schlicht falsch.

Damit werde ich Daten, die z. Z. in einer parallelen Datei geführt werden ("related item") nicht wie geplant in Dateiattribute überführen können. Als Konsequenz müssen meine macOS- / iOS-Applikationen bei Datei-Operationen weiterhin zwei Dateien parallel handhaben - die Verwendung eines File-Wrappers (Verzeichnisses) ist leider keine Option, da die Benutzer weiterhin Zugriff auf die Original-Datei benötigen.

Ich vermute stark, dass dies ein K.O.-Kriterium für die Verwendung des UIDocumentBrowserViewControllers ist ... eigentlich mein Plan für die nächste Version der iOS-App, der gerade angesichts der kommenden USB-Unterstützung eine extrem coole Verbesserung wäre: Meine Benutzer übertragen die Orginal-Dateien sehr viel auf USB-Medien. Hier werde ich aber noch einmal genau forschen, ob sich das Handling des relative items nicht über eine geschickte Implementierung von UIDocument lösen lässt.

Hat vielleicht jemand von Euch Erfahrung mit dem parallelen Verwalten (lesen, schreiben, umbenennen, verschieben, ...) von mehreren Dateien - die als "related items" fungieren - in UIDocumentBrowserViewController resp. UIDocument?

Mattes

Vor einer Woche erhielt ich im Apple Developer Forum einen Hinweis auf diesen Artikel. Demnach kann man durch Anfügen eines Buchstabens an den Attributnamen weitere Eigenschaften setzen, z. B. XATTR_FLAG_SYNCABLE („#S“), um Attribute mit zu synchen.

Wenn ich das entsprechende Projekt wieder hervorhole, werde ich wohl den alten git-Branch wiederbeleben und einen erneuten Versuch starten. Zumal diese App inzwischen auch eine QuickLook-Extension hat und „Open in Place“ unterstützt, was die Vorteile der UIDocumentBrowserViewControllers noch deutlicher macht...

Mattes

Die letzte zwei Tage habe ich hier (erneut) erste Schritte unternommen: Das o. g. Flag "XATTR_FLAG_SYNCABLE" zieht, durch Anfügen von "#S" zu meinem Attributnamen wird dieses auch über iCloud synchronisiert.

Die entsprechenden Klassen des Datenmodells sind angepasst, nun werde ich noch etwas Aufwand in Migrationsverfahren für die macOS- und iOS-App stecken. Nach einer Übergangszeit ist dann der Weg für ein iOS-Remake per UIDocumentBrowserViewController bereitet ... und mein Quick-Look-Problem mit related items ist dann auch Geschichte: Es wird alles viel einfacher

Mattes