I don’t think you are understanding what I’m saying. A PTR update will trigger Live and Beta Updates. Until recently, a Beta or Live update would trigger Live, Beta, and PTR updates. It became a cascading issue. 3rd party stuff isn’t needed to trigger it. Its been partially fixed - at least with the beta Battle.net client.
I’d love to see some evidence of the Mac team being dissolved. I can’t find any.
In fact, Shadowlands includes an ARM64_BUILD string, almost certainly so they can support the Apple Silicon machines releasing later this year.
As far as why it takes months, I would imagine that this bug would be considered pretty low priority just because it is only causing extra updates to occur and not actually breaking the game or causing crashes. Its a subtle bug - is it the launcher thats is broken? the agent? the CDN? the build system? It takes time to figure it out.
Even on Windows, I wouldn’t give it top priority. Annoying? Sure. Hair-on-fire and developers being called on a Sunday? Hardly.
I use the beta client. It isn’t fixed. Any update from any of the branches (Live, PTR, Beta) will trigger the fake update without fail.
At this point, I can only surmise that if the files the Battle.net app looks at don’t have a later touch timestamp than the last timestamp it checks internally, it also triggers the fake update. That’s the only reason I can think of as to why even with everything correctly done it still does the fake update the moment it finishes a previous fake update. I’m wondering if this could be solved by simply having the Battle.net app automatically do a recursive touch on everything in side the WoW folder as its final step in patches and updates. That way the files would always have an equal to or later touch timestamp than the Battle.net app expects. I suppose one way to test this theory would be to set everything up correctly, then touch every file in every folder in the WoW nested heirarchy, but doing so manually is…tedious and it’d be better to just automate it from within the Battle.net app itself.
You won’t see any “evidence” in the sense you’re talking about. But I guarantee you Omegal knows more than you and more than me. If there was still a dedicated Mac platform team, Diablo 3 would have been moved to Metal already instead of left to languish and be damn near unplayable on modern macOS versions in many cases (it’s still using OpenGL, and OpenGL support is spotty at best for AMD hardware in 10.14+).
As for the ARM64 strings, apparently conversion to that architecture from x64 is moderately painless. Barring specific instructions such as AVX2, AVX512, or AMD’s 3D Now!, nearly all of the code is capable of being compiled for Apple’s ARM machines. Now, whether it can run decently is another story, but getting there isn’t death defying like it was going from PPC to x86/x64.
I been having the same problem for months now. I’ve tried a lot of the suggested fixes here but what finally seems to have killed the issue is blowing away the /Users/Shared/Battle.net folder. Next time the Launcher started the directory was recreated. I had to go and tell the Launcher where WoW and Diablo 3 were installed, but other than that, things seem to be back to normal. We’ll see if it lasts.
I followed Aunin’s instructions with some minor modifications:
Go to Terminal
Type ‘crontab -e’
The Crontab will open. Press ‘i’ to insert a new line.
Copy and paste ‘*/1 * * * * chmod 777 /Applications/World\ of\ Warcraft/.build.info’ (not including the quotes) onto the first line
Press ‘esc’ (Escape)
Press ‘:’ (colon)
type ‘wq’ to save the Crontab
This will run a script in the background every 1 minute that resets the permissions on the ‘.build.info’ file from 666 (read-write) to 777 (read-write-execute). The reason you want to use the Cron is because every time you install a Battle.net update, or install a new add-on, the permissions get reset to 666, which is the issue.
No. You just set it and leave it. If Blizzard ever fixes the bug, you can use ‘crontab -r’ to remove it and ‘crontab -l’ to list all crons to ensure it was removed.
They managed to make it even worse. with 9.0 now it’s downloading 8Mb and 20MB manifests/indices just to fake patch. I literally reinstalled game data 2 months ago and already seeing popin and slower loading, on an ultra fast NVMe drive. the literal worst thing you can do on an APFS volume, is touch files over and over and over again, on top of fact CASC is a severely fragmented format too. add in fake patching and you have a trifecta that makes even the fastest 2000+ MB p/s ssd storage have slow loading
only fix, reinstall wow. used to need it every 3 months, now it’s more like every 1-2 to keep game speed. now blizz can’t fix how much APFS sucks, but casc and fake patching are two issues they could fix if they cared, but they don’t.
Heh. My manifests are 100-120 MB. On a fresh install that somehow had to update the instant it finished patching. It does get a bit frustrating after a while.
I don’t know yet whether the crontab entry works to stop the fake updates but I love the detailed vi instructions!
update: It seems like the same size manifest is occasionally being downloaded again, but overall there is much less updating with the cron job in place to reset permissions of the .build.info file.
Not sure if its a permissions issue with .build.info. or mac issue, but you can fix it with Batchmod temporally , but when there is an actual update, it will revert. Blizzard are intentionally ignoring this thread because they believe it isn’t game breaking enough to matter. The issue is really annoying but it’s not stopping us from playing. I do hope they fix it soon, but at this point I have little faith in Blizzard since it’s been an issue for such a long time and like you said, they are basically throwing it under the rug and ignoring us. The only way to fix this right now is turning off Auto Updates.
