OneDrive causes extended fileproviderd CPU activity, hurts battery life

UPDATE possible solution: Try OneDrive's bundled reset script https://support.microsoft.com/en-us/office/reset-onedrive-34701e00-bf7b-42db-b960-84905399050c 

Wasn't sure where to post this since there's no OneDrive topic.

I’m using OneDrive insider preview 21.225.1031.0005 on macOS 12.0.1, M1 MacBook Pro. Even when I am not interacting with any files in the OneDrive folder, OneDrive regularly has several seconds of 200+% CPU usage. Immediately after, fileproviderd has long periods of 90% CPU use. This is lousy for battery life. I found at least one mention on Twitter of the same thing. The OneDrive CPU activity is likely not new, but I presume fileproviderd is new with the new OS.

I have 15,000 files synced with 12,000 set to “always keep on this device”. (My account has one very large folder that is excluded from syncing.) I watched a couple times and saw that OneDrive app activity triggered about 2 minutes of fileproviderd activity. Since the OneDrive app often has activity even when I’m not doing anything, this means fileproviderd runs *a lot*.

When this happens, Console shows hundreds of lines like these (in big groups of similar lines; these samples did not come next to each other):

default 09:31:09.436927-0800 fileproviderd ✍️  FP snapshot mutation: update<s:16420 p:16357 n:"a{59}m.jpg" doc sz:9456 m:rwx%<0> ct:1569351878.0 mt:1569351879.0 v:sver:{blob142} cver:{blob139} nsattr:<cap:rwdpf-e- ul:uploaded deco:<com.microsoft.OneDrive.FileProviderBadges.Pinned.Shared> userInfo:<21 keys>>> diffs:structure why:item changed



info 09:31:09.443150-0800 fileproviderd ✍️  reconciliation update:     <fs:✅  docID(6521) content:watch sver:fileID(46661205)/b{38}m.jpg cver:46662408@2:sz:165242> <-> <fp:✅  16288 content:watch sver:{blob142} cver:{blob139}> doc sched:utility#1637083869.443043 rank:1637083696518411264



info 09:31:09.615397-0800 fileproviderd ┏333ca  �� trigger: <private>



info 09:31:10.044795-0800 fileproviderd item changed <FPItem 0x1209be840:16603 f:"b{82}m.jpg" p:16582 sz:131 KB cap:rwet bt:1569351583 mt:1569351584 mode:rwx-- uti:public.jpeg ul:uploaded dl:fault>, rules: []

They all seem to refer to nonsense file name strings like a{59}m.jpg and b{82}m.jpg. Those names do not exist in my OneDrive.

I would most like to know if this is a Microsoft problem or whether I should open an Apple bug report.

This enduringly bothersome problem lingers, and it's disheartening to note that Microsoft hasn't issued a comprehensive OneDrive update to resolve the issue.

As a temporary workaround, I've taken to intermittently starting up OneDrive, permitting it to synchronize, and then promptly closing it.

It's worth mentioning that even upon closing OneDrive, the fileproviderd process persistently consumes CPU resources for a defined period (approximately 15 minutes), yet eventually subsides from the roster of top CPU consumers.

None of this was any help at all for me. Reset OneDrive. Deleted empty files. Ran fileprovidercheck blah blah. It was good for one or two boots, and now it's back to burning CPU for 5 minutes at a time for no reason when I save a file, or even when I boot and log in. I think there must be some interaction between OneDrive and fileproviderd that is inefficiently written.

And why shouldn't I be able to have empty files, and directories with periods in the name? If I save a project with a nodejs installation in it, for examples, lots of developers leave around empty .gitkeep files to keep a directory structure they need. Maybe I created a notes.txt file and saved it without typing anything. So what. None of that should affect performance of cloud file sync.

It's the first line:

UPDATE possible solution: Try OneDrive's bundled reset script https://support.microsoft.com/en-us/office/reset-onedrive-34701e00-bf7b-42db-b960-84905399050c

The latest update, v22.196.0918.0001 is stable for me.