Hi Matt! Seemingly overnight the disk space used by Arc Editor has grown tremendously: it’s now using 27G on my iPhone
On the other hand I also continue to use the old Arc Timeline simultaneously. It’s still using 6.9GB. This may have been caused by a very long-running activity model update I think.
Yeah this does look suspect. Something fishy going on here. Mine is also up to 16 GB. Not quite as high as yours, but still ~2x what it should be.
I’ll investigate…
Ok, so, iOS is a big fat liar.
From every angle we look at it, its numbers don’t add up. Like, they’re wildly fictional, no matter how you try to account for it. If you think “ok it must be Arc Editor + the App Group + iCloud Drive”, even then nope, no, not at all. It doesn’t add up. iOS’s number is still way over that.
Which is not at all a satisfying answer. And my impression is that iOS acts on its own lies - it thinks those numbers are real. But… those gigabytes? They’re not in Arc Editor’s files, not in iCloud Drive, not in the AppGroup. It’s fiction.
So what we’re gonna do is add a new view to the app that shows you what the files in the app actually are, and how big they actually are.
That won’t fix the problem of iOS telling wild lies, or acting on those lies, but it’ll at least let us know what the real situation is.
Great idea! I very much like it, even if only to understand where this comes from.
I found a large source of disk space usage! Basically there was a log file in debug logs that I couldn’t open ( Arc editor battery usage - #7 by trackerminerfs ). I had a hypothesis that maybe it’s because the log file is so huge. So I deleted that one log file. Then the Arc Editor disk usage went down to 9.4GB!
Well that’s… quite weird!
The logs files… it’d basically be physically impossible for them to get that big. So I think it won’t have been that specific log file that was the problem, but… ok I’m going to get a bit speculative here. We’ve really got almost nothing to go on in terms of accessible evidence.
But my speculation is that iOS isn’t calculating those storage amounts in real time, it’s calculating them periodically. And it’s possibly also calculating them to include… well, now I’ll really be speculating, but it could be system log files, temp files, all sorts of things that aren’t part of the app container or App Group or anything we’ll ever be able to see.
And then when you deleted that big log file, my assumption is you triggered iOS to do a recalculation. At which point it managed to do the maths much better than previously. It’s likely still including random system bits in the count, which it probably shouldn’t. But yeah, deleting the log file → triggers a recount → more accurate count this time.
And I think a key clue there is the count dropping from 27GB to 9.4GB. That’s a drop of ~17GB! That’s an incredible amount, that can’t plausibly be attributed to anything inside the app (or the App Group, and probably not even iCloud Drive). And genuinely deleting 17GB of data wouldn’t happen in a second, it’d take minutes to do for real.
So yeah, I’m still of the strong opinion that iOS is just straight up lying. And also that there’s next to nothing we can do about it (other than build this new view that’ll tell us what’s actually there). But at least @trackerminerfs your log file deletion shows us that it might be possible to push iOS into rechecking its maths and partially fixing it!
Good morning,
This happened to me too, on v38 overnight.
It’s definitely a log that got out of hand (or, as you speculate, that iOS thinks got out of hand)
You wrote “it’d basically be physically impossible for them to get that big.” Really? Is there something that would prevent an infinite loop from logging as fast as it can, for 9 hours, and making a 10 GB log?
I can’t view it through the Arc log viewer, but is there any other way for me to get my hands on it, so we can see what’s in it before I delete it?
Thanks!
Wow! That’s… I’m really surprised iOS allowed that at all. You’d think it’d terminate an app that’s doing that in the background. And I can’t imagine any case inside the app where it’d get into such a loop. Wild.
Yeah in Finder in your screenshot, you can drag that whole Logs folder to somewhere local, and have a look inside it there. Presumably it’ll stand out quickly what the repeated line is…
Sure enough, it’s a 10.77 GB log. Are you ready???
[23:27:24.002] [ACTIVITYTYPES] Skipping duplicate ActivityTypesManager.updateModel(geoKey:) for CD2 25.75,-79.55
…around 3000 times a second, until it ran the phone out of storage a little over 9 hours and 95 million iterations later.
Eek! That’s not good. Though at least that’s a super clear and obvious cause, and will be easy to fix. I’ll get onto that right now, and hopefully get a new build out today. Don’t want that happening again!
iCloud was getting low so I checked my backup and probably found the reason (I don’t know if this is related to the OP.)
As an aside question, can I delete one of the apps?
Hi @diligiant!
Can definitely delete Arc Mini entirely, ie delete the app from your phone. That one’s long dead.
Is that screenshot of the Backup Details view? Yeah, just checking on my phone, it looks the same as that.
For the rest… those sizes are insane. For comparison, mine look like this:
I don’t know why they would all be so large on your phone, but the first thing to check will be in Arc Editor → Settings (top left button) → Debug Logs. Look for any … actually, you could just tap “Delete all”. It’s not necessary to keep those around unless you’re debugging something specific.
There was a bug fixed in yesterday’s build (make sure you’ve got auto updates turned on in TestFlight) that fixed an edge case that could result in a log file growing absurdly large. So getting rid of those old log files could shrink the disk space usage down significantly.
Now to your original question: You could turn iCloud Backups off for Arc Recorder, and also Arc Timeline. Just leave it on for Arc Editor.
But yeah, definitely delete all the log files, and then after that check what disk space usage looks like. I suspect the Backup Details numbers won’t change until a new backup has completed though.
