# Arc Editor Backup structure **URL:** \ **Category:** Features Discussion\ **Created:** [6 March 2026 06:07 UTC](https://support.bigpaua.com/t/arc-editor-backup-structure/1104 "2026-03-06T06:07:16Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![zzGordon](https://dub1.discourse-cdn.com/flex013/user_avatar/support.bigpaua.com/zzgordon/32/1238_2.png) [@zzGordon](https://support.bigpaua.com/u/zzGordon)\ **Post date:** [6 March 2026 06:07 UTC](https://support.bigpaua.com/t/arc-editor-backup-structure/1104/1 "2026-03-06T06:07:16Z")
Hi Matt, I’ve been having some problems affecting some days when importing from the Arc Editor backup. I’m currently using 1.0 (37). ![Screenshot 2026-03-06 at 4.05.01 pm](https://europe1.discourse-cdn.com/flex013/uploads/bigpaua/original/2X/5/5aeb58d81f4fc14f3680eb8784ef347524369527.png) Here’s an explanation from GPT-5.3-Codex. Claude Opus 5.4 went down a deep rabbit hole and never returned trying to fix this one! * * * I’ve found a backup consistency issue in Arc Editor sample exports that is causing missed GPS data in downstream importers. For backup ID 26DD32A8-63E3-422E-92CB-C3321569E72B, timeline items for **2016-01-02** import correctly, but the GPS samples for that day are not in the expected week file. Specifically: - 2016-01-02 samples are present in 2015-W01.json.gz - That file’s sample dates run from 2015-12-28 to 2016-01-03 - Importers that select sample files by week-key filename (e.g. 2015-W53 / 2016-W01) can miss the correct file and attach zero GPS samples to activities So the underlying GPS exists, but filename-based week selection fails because file naming and contained date ranges are not consistently aligned. Could you confirm the intended naming contract for YYYY-Www.json.gz and whether this historical mismatch is expected? If possible, a robust fix on Arc Editor side would be either: 1. Ensure filename week keys always match contained sample date ranges, or 2. Include a manifest with min/max date per sample file so importers can select files by actual date coverage. This would prevent data-loss behavior in consumers and avoid expensive broad file scanning fallbacks. * * * The fallback has been implemented and testing is underway. ”The GPS sample fallback scan is now complete for both import paths. The approach: - **Primary load** uses week-key matching (unchanged, fast) - **Fallback** activates only for items that got zero samples — probes skipped files by date range, loads matching samples, and caches the `dayKey → weekFileKey` mapping so subsequent imports skip the probe - **Memory-efficient** — only loads one fallback file at a time per affected day, doesn’t bulk-load adjacent years” Regards Gordon ---
**Author:** ![zzGordon](https://dub1.discourse-cdn.com/flex013/user_avatar/support.bigpaua.com/zzgordon/32/1238_2.png) [@zzGordon](https://support.bigpaua.com/u/zzGordon)\ **Post date:** [6 March 2026 06:43 UTC](https://support.bigpaua.com/t/arc-editor-backup-structure/1104/2 "2026-03-06T06:43:11Z")
Hi Matt, The fallback update is up! Arc Reader, Build 02.166. Fortunately, there were only 4 days affected out of a total of 4,478 days! ![Screenshot 2026-03-06 at 4.37.17 pm](https://europe1.discourse-cdn.com/flex013/uploads/bigpaua/original/2X/4/48a3230d01b7bbde68ab33ffdb0c18fd49840d50.png) 🔍 GPS fallback scan resolved 4 day(s) with mislabeled sample files ---
**Author:** ![matt](https://dub1.discourse-cdn.com/flex013/user_avatar/support.bigpaua.com/matt/32/3_2.png) [@matt](https://support.bigpaua.com/u/matt)\ **Post date:** [7 March 2026 03:33 UTC](https://support.bigpaua.com/t/arc-editor-backup-structure/1104/3 "2026-03-07T03:33:25Z")
> [@zzGordon](#): > > I’ve found a backup consistency issue in Arc Editor sample exports that is causing missed GPS data in downstream importers. Curious! Looking into it now on my side. Oh can also point Claude/Codex to the most likely offending file too: > Hah. And Claude’s already found it after reading your forum posts: > Found it. The bug is on line 552: > > let year = calendar.component(.year, from: currentWeekStart) > > This uses .year (calendar year) instead of .yearForWeekOfYear (ISO week-numbering year). Near year boundaries, > these differ. For example, 2015-12-28 is a Monday that starts ISO week 2016-W01, but .year returns 2015, so > the file gets named 2015-W01.json.gz instead of 2016-W01.json.gz. > > That’s exactly Gordon’s bug — his 2016-01-02 samples ended up in 2015-W01.json.gz because the week started on > 2015-12-28. > > The fix is one line: .year → .yearForWeekOfYear on line 552. K, fixed now. Will be in next build 👍🏼