OneDrive causes extended fileproviderd CPU activity, hurts battery life

Anonymous

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.

Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.

0 comments

53 answers

Anonymous

2024-01-05T08:37:20+00:00

I've tried this solution on both my MacBook Pro and Air, and after a few hours, the problem still comes back.

Did you try the reset script that's linked at the top of the original post? I'm the original poster. I do not think I have had the problem in a long time, maybe since running that script.

Like some commenters, I would say it's reasonable to suspect Apple bugs as the ultimate cause. Hard to say though.
Was this answer helpful?

0 comments No comments
Jim G 134K Reputation points MVP

2024-01-04T13:30:06+00:00

This Q&A is in the beta channel thread.

There is a forum category devoted to OneDrive for users of regular distributions of Office. It's here: https://answers.microsoft.com/en-us/msoffice/forum/msoffice_drive?sort=LastReplyDate&dir=Desc&tab=All&status=all&mod=&modAge=&advFil=&postedAfter=&postedBefore=&threadType=all&isFilterExpanded=false&page=1
Was this answer helpful?

0 comments No comments
Anonymous

2023-12-01T17:17:44+00:00
Hi everyone.

This solution helped me, altough I removed the files manually.
```
find . -type f -empty
```
Running fileproviderctl check -v after deleting the empty files found by the previous command, shows there are still some files with errors (some "is_filled_with_zeros", "is_evictable_without_flags|is_purgeable_not_evictable") but apparently that does not increase CPU activity.

I also ran fileproviderctl repair -v at the end, nothing changed much, though.

One thing I tried to do is search for the files that are shown by fileproviderctl check, based on the last character and the extension (like z.png, or *z.png), and I couldn't find any, neither locally or in the web portal. So either the entire route and filename are encrypted (and the last character on the name is part of the encrypted text), or maybe these are files already deleted and they're not actually on any of the folders.

Now, the final output I get with fileproviderctl check -v is
```
FPCK for XXXXXXXXXXXX:

❌ disk <-> FSSnapshot failed on 17/29804 files. 

✅ FSSnapshot <-> FPSnapshot succeeded on 29804 files. 

✅ ReconciliationTable checks succeeded on 29804 files.
```
Was this answer helpful?

0 comments No comments