However, at the moment I’m ready to post this, these entries have finally gone away, of course! So maybe not something with EF at all. No (obvious) EF file open by cloudd at the moment and it’s still at 835%.
I’ve continued to struggle with extreme high CPU and load issues with cloudd and believe I have identified it as related to EF.
Whenever I am running EF, cloudd struggles to upload Main Library.eflibrary (this file is 600MB) and .EagleFiler Metadata.plist at the top level of Files (2.7MB).
If I quit EF and do a killall bird && killall cloudd, those EF files immediately begin to sync to iCloud and do finish. Things are calm until I relaunch EF.
I thought maybe 14.1 macOS might help, but it made no difference.
Yesterday I disabled the macOS feature “Sys Prefs → Apple ID → iCloud Optimize Mac Storage” as I don’t recall I ever had that on prior to Sonoma and thought maybe it was a new default). That finished pulling things down and it made no difference either.
Yesterday I quit EF, killall bird && killall cloudd and went about my business. All things were calm until this morning when I started work and launched EF. cloudd got stuck on Main Library.eflibrary and my MacBook became unusable with high CPU/load. I quit EF, restarted bird/cloudd, cloudd did sync, and things remained calm until I started using EF again.
I researched methods to exclude cloudd sync of particular folders and files. It seems you can add an extension (after the “real” file extension) to exclude it, but I wonder if that would break EF.
Alternatively I could move my EF library out of iCloud Drive, but I put it there so I could access everything in “Files” on my iOS devices.
I’m not hearing other reports of this, but it does seem as though Apple rewrote iCloud Drive for Sonoma. The .eflibrary file is actually a package (folder). Are you able to see with Cirrus which files inside it are bogging down the syncing?
EagleFiler does keep a Temporary Items.nobackup folder inside of the .eflibrary, which sees lots of new files, but they’re all inside of a iCloudDrive.nosync folder, which should prevent them from being uploaded to iCloud.
If it’s the Records.efindex, that’s not excluded from syncing, and that file can indeed be large. But it’s just a regular file. That shouldn’t cause iCloud to use lots of CPU unless there’s a bug.
One option would be to move the whole library folder out of iCloud Drive. You could then move the Files folder to iCloud Drive and replace it with an alias. That way you would still be able to access the files from iOS, but the indexes would not sync.
I launched EF and immediately the iCloud Drive says it’s uploading 500 MB consisting of 2 files.
Cirrus shows me Main Library.eflibrary has an “uploading” status, but when I drill into Main Library.eflibrary, Cirrus doesn’t show a status for any of the items therein. All the status boxes are blank for all files inside the package file/dir. Maybe a bug?
The weird thing is cloudd is using 600-800% cpu while it’s uploading these 2 EF files. That in itself should never be happening no matter what it’s syncing. Ugh.
At the moment syncing activity has stopped, the icon next to the “iCloud Drive” line in the Finder sidebar now has an exclamation mark in a spinning arrow circle, and the CPU is pegged. It says “iCloud Status There are pending items to sync.”
I’m going to move stuff around like you suggested now and see how it goes.
I wonder if iCloud Drive has changed so that it now sees the entire package as a single unit to sync, so that it no longer even looks for the .nosync exclusions or tracks progress for other files inside.
Agreed. Nor should a 2.7 MB plist file cause problems.
File is now by itself in iCloud Drive. I made a symlink to it in the EF library dir.
So far so good. That’s 500MB less in my iCloud Drive as a bonus.
Interestingly iCloud didn’t seem to resync “Files” even though I moved it out with the library and then moved it back into iCloud Drive in a “different” path. All the files are still immediately accessible on my iPad. So I guess it does have some smarts.