@wollnyst, not yet solve it.
I thought Apple just still working on it, and we're operating on a black box.
I hope if Apple finally got this released, a sample code would be a great relief to us.
Post
Replies
Boosts
Views
Activity
Hi again, @Laszlo.
Can you upload your current working sample code to GitHub for example?
After signaled enumerate root container, I failed to establish the connection with my File Provider Extension.
I cannot figure out the reason behind it, maybe your sample code is helpful to me. :-P
Hi, @Laszlo - https://developer.apple.com/forums/profile/Laszlo.
Can you describe the detail of how you register and load the File Provider Extension?
I managed to change the Info.plist, yet I failed to launch the File Provider Extension.
In my investigations:
OneDrive can run in Big Sur without FileProvider, in OneDrive, each placeholder file have a xattr named com.apple.fileutil.PlaceholderData, and bound with a launch service xattr com.apple.LaunchServices.OpenWith.
Evidence:
$ xattr -l 'Getting started with OneDrive.pdf'
com.apple.LaunchServices.OpenWith:
00000000 62 70 6C 69 73 74 30 30 D2 01 02 03 04 57 76 65 |bplist00.....Wve|
00000010 72 73 69 6F 6E 5F 10 10 62 75 6E 64 6C 65 69 64 |rsion_..bundleid|
00000020 65 6E 74 69 66 69 65 72 10 00 5F 10 24 63 6F 6D |entifier.._.$com|
00000030 2E 6D 69 63 72 6F 73 6F 66 74 2E 4F 6E 65 44 72 |.microsoft.OneDr|
00000040 69 76 65 2E 44 6F 77 6E 6C 6F 61 64 41 6E 64 47 |ive.DownloadAndG|
00000050 6F 08 0D 15 28 2A 00 00 00 00 00 00 01 01 00 00 |o...(*..........|
00000060 00 00 00 00 00 05 00 00 00 00 00 00 00 00 00 00 |................|
00000070 00 00 00 00 00 51 |.....Q|
00000076
com.apple.fileutil.PlaceholderData:
00000000 44 45 4E 4F 01 00 00 00 03 00 00 00 50 01 00 00 |DENO........P...|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000020 02 00 00 00 30 01 00 00 00 00 00 00 00 00 00 00 |....0...........|
00000030 03 13 06 00 00 00 00 00 33 32 37 33 41 46 43 44 |........3273AFCD|
00000040 35 36 41 41 36 45 35 37 21 31 30 32 00 00 00 00 |56AA6E57!102....|
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000060 33 32 37 33 41 46 43 44 35 36 41 41 36 45 35 37 |3273AFCD56AA6E57|
00000070 21 31 30 32 00 00 00 00 00 00 00 00 00 00 00 00 |!102............|
00000080 00 00 00 00 00 00 00 00 33 32 37 33 41 46 43 44 |........3273AFCD|
00000090 35 36 41 41 36 45 35 37 21 31 30 31 00 00 00 00 |56AA6E57!101....|
000000A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000000B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000000C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000000D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000000E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000000F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000120 00 00 00 00 00 00 00 00 33 32 37 33 61 66 63 64 |........3273afcd|
00000130 35 36 61 61 36 65 35 37 00 00 65 00 74 00 74 00 |56aa6e57..e.t.t.|
00000140 69 00 6E 00 67 00 20 00 73 00 74 00 61 00 72 00 |i.n.g. .s.t.a.r.|
00000150
OneDrive seems utilized the com.apple.fileutil kernel extension via kernel control sockets.
$ kextstat | grep fileutil
	161		0 0xffffff7f81773000 0x18000		0x18000		com.apple.fileutil (20.036.15) E3E63A3C-BE10-3DB3-A89F-F2313C192EB0 <6 5 3 2 1>
$ netstat -n
...
Registered kernel control modules
id			 flags		pcbcount rcvbuf	 sndbuf	 name
			 d				0				1		 8192		 8192 com.apple.fileutil.kext.stateful.ctl
			 e				0				3		 8192		 2048 com.apple.fileutil.kext.stateless.ctl
...
Yet the document is only available to Apple and OneDrive.
And as far as I know, the com.apple.fileutil kext come as early as in macOS 10.14
The similar pattern also apply to Dropbox as I rechecked Dropbox in Big Sur recently:
$ pwd
~/Dropbox
$ xattr -l 'Get Started with Dropbox.pdf'
com.apple.metadata:_kMDItemUserTags: <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"><plist version="1.0"><array><string>Online-only</string></array></plist>
com.dropbox.attrs:
00000000	0A 12 0A 10 9F B5 39 2F 57 E3 32 10 00 00 00 00	|......9/W.2.....|
00000010	00 00 00 05 10 E4 FF B9 82 03										|..........|
0000001a
com.dropbox.placeholder:
00000000	03 00 00 00 AC 18 A3 2B 00 00 00 00 0A 12 0A 10	|.......+........|
00000010	9F B5 39 2F 57 E3 32 10 00 00 00 00 00 00 00 05	|..9/W.2.........|
00000020	10 E4 FF B9 82 03																|......|
00000026
$ netstat -n
Registered kernel control modules
id			 flags		pcbcount rcvbuf	 sndbuf	 name
...
			 b				4				0		32768		 2048 com.apple.fsplaceholder.logging
			 c				4				1		32768		16384 com.apple.fsplaceholder.kauth
...
$ pwd
/Applications/Dropbox.app/Contents
$ strings Frameworks/python-extensions/macinfinite_native.cpython-37m-darwin.so | grep fsp
infinite_dbkext_load_fsplaceholder_kext
infinite_dbkext_unload_fsplaceholder_kext
k_infinite_kauth_fsplaceholder_kern_control_name
com.apple.fsplaceholder.kauth
load_fsplaceholder
release_fsplaceholder
$ pwd
/System/Library/Extensions/FSPlaceholder.kext/Contents/MacOS
$ strings FSPlaceholder | grep -i dropbox
com.dropbox.placeholder
.dropbox.cache
Dropbox
$ nm FSPlaceholder | grep sysctl__
U _sysctl__vfs_children
0000000000005108 D _sysctl__vfs_fsplaceholder
0000000000005260 S _sysctl__vfs_fsplaceholder_children
0000000000005210 D _sysctl__vfs_fsplaceholder_connected_clients
00000000000051a8 D _sysctl__vfs_fsplaceholder_connected_logging_clients
0000000000005158 D _sysctl__vfs_fsplaceholder_kext_version
Before we launch Dropbox.app
$ sysctl vfs.fsplaceholder
vfs.fsplaceholder.kext_version: 1.13.2
vfs.fsplaceholder.connected_logging_clients: 0
vfs.fsplaceholder.connected_clients: 0
After we launched Dropbox.app
$ sysctl vfs.fsplaceholder
vfs.fsplaceholder.kext_version: 1.13.2
vfs.fsplaceholder.connected_logging_clients: 0
vfs.fsplaceholder.connected_clients: 1
vfs.fsplaceholder.connected_clients down to zero after we closed Dropbox.app
Like before, no document at all, exclusive support for Dropbox.
So both Microsoft and Dropbox have corporation with Apple before the macOS FileProvider API is ready.
Which is unfair to many of us who used deprecated KPIs, we now cannot use FileProvider, and EndpointSecurity can't suit in our use cases.
And our customers complain about why your app is malfunctioned.
We have urged(via feedback) to speed up development of macOS FileProvider API, which Apple, disappointed us for a long time.
Hi, All, does there any sample code for macOS FileProvider API?
I cannot find any sample code in https://developer.apple.com/documentation/fileprovider/macos_support.
I don't know how to load a FileProvider API currently, is there anyone can help with this?
As I recently rechecked the FileProvider - macOS Support page, surprisingly, the page got updated.
https://developer.apple.com/documentation/fileprovider/macos_support-ari
Https://archive.is/BPFDB
But there seems have no sample code for macOS, also I don't know how to load the file provider extension in my test app... anyone got any idea?
It seems that NSFileProviderReplicatedExtension still in beta state.
macOS 11.0 beta 10, Xcode 12.2 beta3
The code written in Swift
BTW, Objective-C still cannot compile the NSFileProviderReplicatedExtension, it complains
'NSFileProviderExtension' is unavailable: not available on macOS Very likely being a bug of Xcode beta.
Can someone confirm if this new macOS 11 API is something we can use to build file provider extensions? When you build a demo macOS app with NSFileProviderExtension, you'll get the error: 'NSFileProviderExtension' is unavailable in macOS.
Confirmed in macOS 11 Beta 4(Xcode 12 Beta 4)
I presumably though that macOS NSFileProviderExtension isn't ready yet.
The file provider extension support is actually included in the current macOS Big Sur Beta, and the new APIs for macOS support are listed here: https://developer.apple.com/documentation/fileprovider/macos_support Hi, DTS engineer, does this meaning that FileProvider API now available and runnable in macOS 11.0 Beta?
Hi, @eskimo. After I followed your link.
Retest With a Small Test App I used a test app for notarization test, like what your said, This is unlikely to fix the problem, but it confirms that there’s an issue with your account, not your product.
There's certainly something wrong with my account.
Double Check Your Agreements After we open App Store Connect > Agreements, Tax, and Banking - https://appstoreconnect.apple.com/agreements/, we found we had only the Paid Apps agreement inactive.
We success to notarize our apps after we agreed to the Paid Apps agreement(Active status).
Thus the statement Note You do not need to agree to the Paid Apps agreement to use the notary service. may wrong in such case.
There're three cases for Paid Apps agreement:
Paid Apps agreement has never been agreed, thus Note You do not need to agree to the Paid Apps agreement to use the notary service.
Paid Apps agreement agreed previously, and updated by Apple recently, in which case you should stick to the latest agreement for notarization service to work.
Apple changed its rule, you need to agree all agreements so you can use notarization service.
I don't know which case it belongs to by now, anyway, there is an exception to the statement Note You do not need to agree to the Paid Apps agreement to use the notary service.
The NSFileProviderExtension API is not formally shipped for macOS yet. If your app has use cases relying on it, please file feedback for us to vote the priority. Please post your feedback ID here if you do it. Thanks. Hi, DTS Engineer, how is the progress of NSFileProviderExtension API as of July 3, 2020?
Since macOS 10.15 is the last macOS that can load deprecated kernel extension, and macOS 11.0 Big Sur won't load kext with deprecated KPIs.