Re: The endless influx of low-quality, low-realism, quantity-over-quality aircraft into FGAddon

here you go......


   1. I had an attempted x0x upgrade by on my Windows laptop (daemon
   running in background), which clearly kept failing, and it would keep
   re-downloading the update, leading to a 60gb folder by the time I did the
   upgrade manually. Thankfully I caught it then, or it may have filled up my
   drive [image: 🙂] Also; glad I'm not on a metered connection [image: 😆]
   2.  [ANT],
   [10:09 PM]dirvine [ANT], :
   what was it doing? was it copying the same file to different filenames?
   Did you type x0x upgrade and what did it print out.
   3. [10:48 PM]DavidMc0 [ANT], :
   I wasn't using the computer today, but this evening had a look & saw
   there was an upgrade on the Communitas GUI. I downloaded the latest upgrade
   from Github & went to delete the old x0x folder, but when it showed it was
   a 60gb folder I thought I should check it out. In the folder there are
   1,122 folders made between 20:52 last night & 21:11 tonight. Each folder is
   54mb and labelled .x0x-upgrade-(numbers). I guess it got stuck in an
   upgrade attempt loop or something, though I didn't intentionally initiate
   an update.
   4. [10:49 PM]DavidMc0 [ANT], :
   Most of the folders have 'archive' 'archive.sig' and 'extracted-binary'
   in them.
   5.  [ANT],
   [11:00 PM]dirvine [ANT], :
   Nice catch -- Three bugs, compounding
      1. Windows can never complete the upgrade (root
      cause).Upgrader::atomic_replace (src/upgrade/mod.rs:101) does
      std::fs::rename(new_binary, target) to overwrite the currently running
      x0xd.exe. Windows locks running executables — you cannot rename or
      overwrite one in place. So the rename fails; the rollback then tries
      restore_from_backup → fs::rename(backup, target)(mod.rs:81), which also
      fails because the target is still locked → returns
CriticalFailure. On Unix
      rename over a running binary is fine, which is why this was never caught.
      The upgrade is structurally impossible on Windows as written.
   2. Every failure leaks a 54 MB temp dir. apply_upgrade_from_manifest
      (src/upgrade/apply.rs:94) creates the temp dir, then only cleans it up on
      hash mismatch (:117), signature failure (:131), or the success/rollback
      path that reaches :178. The Windows failure returns early via the? on let
      result = upgrader.perform_upgrade(...)?; at apply.rs:175 — which
skips the
      :178 cleanup entirely. The archive is already downloaded and the binary
      already extracted by then, so the full 54 MB is left on disk.
Exactly your
      folder contents.
   3. No backoff on the gossip path, so it retries forever. The 48h
      fallback poll does track failures (failed_version + 30-min skip,
      x0xd.rs:3188-3221). But the gossip-driven apply loop (x0xd.rs:3030-3167)
      has no backoff at all — it calls apply_upgrade_from_manifest on every
      manifest receipt and just logs the error (:3162). Peers rebroadcast the
      manifest every 5 minutes, and because the node never actually upgrades,
      is_newer() stays true forever. So: receive manifest → download 54 MB →
      extract → fail → leak → repeat, roughly every~77 s in your case.
Unbounded.
   Immediate guidance for the user The 60 GB of .x0x-upgrade-* folders are
   orphaned temp dirs — safe to delete. They are not part of the real install
   (you already did the manual upgrade). There's also no startup sweep that
   would ever reclaim them.
   6. [11:02 PM]dirvine [ANT], :
   Fix will be in place tonight
   7.  [ANT],
   [11:21 PM]storage_guy:
   This is a great example of the openness of this project.
   8. [11:22 PM]dirvine [ANT], :
   Fixed and tested locally now. 6 hour soak test running on another issue
   related to cpu use related to gossip queues and retries. Both should be
   complete by morning. There will be a 4 hour run tomorrow and fix in by
   lunch for both



background
DavidMc0 is a long term supporter, not fantastically technical but knows
the project and its phlosophy - has never contributed  a single line of
code yet is a well loved and  respected community member.
dirvine is our BDFL - although he would hate me saying that......


but just keep deflecting....... and continuing to ignore your core problems.

On Wed, 27 May 2026 at 14:23, <[email protected]> wrote:

> On 5/27/26 9:06 AM, Willie Fleming wrote:
> > Check
> >
> https://discord.com/channels/1209059621319221268/1247881515107483759/1508929040759787610
> > and subsequent messages for an example of how it could and SHOULD be
> done.
>
> sorry... i'm not in the habit of clicking random links... especially those
> to
> some unknown discord with no indication of what it is...
>
> > Then ask yourselves which project would I rather spend my precious free
> time
> > working on?
>
> while this may sound snarky and dismissive, it is not... the fact is that
> you
> are free to do what you like where ever you like... if that's working on
> something else, more power to you... enjoy it and have fun! seriously...
>
>
> _______________________________________________
> Flightgear-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>


-- 
Regards
Willie Fleming

_______________________________________________
Flightgear-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel