Forum Discussion
Major Onedrive Business client continuous sync loop bug
Couple of points (mostly in reply to OP):
First point - this has actually been a "problem" for a considerable amount of time, I recall certainly throughout 2016 as encountering this (personal OneDrive with iTunes library configuration stored there - iTunes causes a write lock throughout the time it's running). Any write lock will cause OneDrive to loop through looking for changed files, as it's reacting to writes. Consequently, I'm not convinced searching for an older client will help.
Most straight-forward way to find the files is looking at the explorer file badges; folders and files with locks will constantly have the blue sync badge over their icon.
Second point - the bit about destroying SSD through NAND writes is completely wrong. If you actually look at the procmon results you'll see the desired access for every file is Read/List + Read Attributes. Additionally, it's not hundreds of gigabytes worth of data since it's just scraping the properties for the file to work out what's changed. You can confirm this by loading up Resource Manager, hitting the Disk tab and (if it even appears) selecting OneDrive.exe.
CPU nor disk performance never spirals out of control, so don't see this as being much of an operational issue.
Luke Gatchell:
Trial and error. Searching and ordering by creation/modified date and working backwards. It sucks as now I have to do it again today as it started again and hopefully is just some simple zero byte file, long path length, etc.
"Most straight-forward way to find the files is looking at the explorer file badges; folders and files with locks will constantly have the blue sync badge over their icon."
This is ludicrious. So much so, that I won't even go on to ask if before you so dangerously stated that "you do not see this as an operational issue", if you have actually DONE ANYTHING on this? Can you provide the research and logs, or are you just here to troll?
I clock this at generating HUNDREDS OF GIGS PER DAY of nand writes due to this behavior - do you know how to operate calc.exe to do that math over even a year? Show me a single recent SSD that can handle that many writes.......they can't and again unlike you I actually DO have dead SSDs to prove this.
I am also well aware that this has been an issue for "some time" as I'm approaching my 30yrs in this business and have literally used Onedrive since it was in limited internal MS testing as Skydrive (for personal), live mesh (before they bought it), and blended it with Sharepoint to make this latest client. It's a mish-mosh, hodge-podge of code from three major sources that makes this latest "next gen" sync client.
Now, with all that said, since I've also been doing development for three decades let me ask, who has the excuse of why this client has been not in alpha or beta, but now in production desktop environments for YEARS yet can't handle the most BASIC of things like zero byte files and simple friggin PATH LENGTH ONE LINE OF CODE tests that I was writing in assembly 30 yrs ago?!?!? What's the excuse as to why, even today in 2017, I literally AGAIN am watching this "next gen" client cycle infinitely on my SSD undoubtedly because of a single zero byte file or long path I need to hunt down, yet STILL CANNOT GET a single simple verbose LOG FILE out of this client indicating WHAT FILE OR FOLDER is even a problem?
.....And if you knew ANYTHING about this client you would know that if you can make it past the ~11 (also horrible coding) hard-coded OS limit in 2017 for simple shell icon overlays, to even SHOW the Onedrive sync icon overlays, you would be well aware that they are HORRIBLY inaccurate at times and in this bug case, can show HUNDREDS of files not sync'd.......know why? Because of the ONE issue preventing it from continuing - yet unlike the cases where it DOES pop up with illegal filename, sharing issues, etc., in this bug case it NEVER INDICATES A SINGLE ISSUE (along with no log), and you can prove all of this in 2 seconds with procmon (MS own tool now since they bought Russinovich) and watch all of this (I think I even already provided a real life video showing it) as it loops through in my case the HUNDREDS OF GIGS in my Ondrive Business structure......and I have yet to find any line/event to easily target the issues and wind up wasting HOURS each time. Last time it was a simple Powershell lock on transcripts that anyone can prove this bug in 2 minutes just by opening a PS transcript anywhere in the Onedrive structure and boom sync loop bug and then leave it on for a year and call me and let me know how that SSD is doing. :)
Sorry but this trolling is absurd when I've even shot VIDEOS of this issue when idiots show up just like if I passed a FATAL car accident on the freeway, rolled my window down, and said to the family of the deceased "this accident is really not a big operational problem in your life", LOL.
I have 155 files right now not syncing because of this issue right now, so you want to tell me again it's "not really an operational issue"? LOL. It really, really, is exactly that - a BIG operational issue that MS should be embarrassed of with this client maturity level and should get on it to eradicate such basic sync problems like this before it bites their paying corporate customers (like me) before they get tired of waiting and just move to a competitor for basic cloud syncing.
I mean, I've been developing for 3 decades, so seriously if MS can't afford friggin putting developers on major basic issues like this that again if I were them would be EMBRARRASED of and would want to squash immediately, then release the source code and I bet between me and the rest of the developers out here using their product daily with skin in the game that we could have this issue eradicated tested and rolled out quickly.
Have similar issues as well with one of our OneDrive for Business users.
I can also reproduce the problem with Start-Transcript, even on current OneDrive client version 17.3.7074.1023
