u/_temple_

Hi all,

I’m hoping someone can help steer me in the right direction.

I bought a Tesla model Y today. 2023 model RWD model.

The car was advertised as having FSD, all the screenshots show self driving included package in software on the car, when I went to view the car it had it enabled too.

It went into Tesla for a horn repair yesterday as the dealer noticed an issue with the horn on the day I went to view. It’s then been delivered to me today by the dealer, I’ve paid for it etc and gone into settings and the FSD features are gone.

I think they’ve removed it when they’ve sorted the horn as they’ve done a software update on the car too.

As far as I was aware, it was tied to the cars VIN and as I say, the listing said it had FSD and was a huge reason I bought this particular car.

Anyone else had similar and had Tesla rectify it? Or if not, managed to get any money back?

I’m in the UK.

Thanks all!

Hi all,

I’m hoping someone can help steer me in the right direction.

I bought a Tesla model Y today. 2023 model RWD model.

The car was advertised as having FSD, all the screenshots show self driving included package in software on the car, when I went to view the car it had it enabled too.

It went into Tesla for a horn repair yesterday as the dealer noticed an issue with the horn on the day I went to view. It’s then been delivered to me today by the dealer, I’ve paid for it etc and gone into settings and the FSD features are gone.

I think they’ve removed it when they’ve sorted the horn as they’ve done a software update on the car too.

As far as I was aware, it was tied to the cars VIN and as I say, the listing said it had FSD and was a huge reason I bought this particular car.

Anyone else had similar and had Tesla rectify it? Or if not, managed to get any money back?

I’m in the UK.

Thanks all!

Side project that turned into a real thing. Wanted a Windows drive-letter sync client for OneDrive/SharePoint with a few specific things off-the-shelf options didn't quite combine (image thumbnails working in Explorer for cloud-mounted files, accurate cloud-quota numbers in the drive-properties dialog refreshed from Graph, local-first sync semantics where files exist as real NTFS first and sync in the background, zero telemetry). Was also curious whether I could build it. Sharing because the war stories along the way might save someone else the hours. Disclosure: I wrote it, MIT licence, link at the bottom.

Stack: .NET 8 single-file self-contained exe, DokanNet for the user-mode to kernel-mode FS bridge, MSAL + Microsoft.Graph SDK, LiteDB for the upload queue and metadata, WiX v6 for the MSI and Burn bundle.

Three engineering bits that were more interesting than I expected:

1. Office AutoSave for third-party providers doesn't have a documented API. Microsoft maintains an internal allowlist of cloud providers Office considers worthy of native AutoSave, and we are not on it. I spent the better part of two minor releases building full CFAPI integration (sync root registration, placeholder lifecycle, the callbacks) before discovering CFAPI registration alone doesn't get you in. The working bridge: register as the default handler for .docx/.xlsx/.pptx, intercept the open, launch Office with `ms-word:ofe|u|<direct SharePoint url>`. Office opens it from SharePoint and AutoSave + co-auth light up. Important detail if you try this: it's the DIRECT SharePoint file URL, not the Graph /_layouts/15/Doc.aspx URL (the latter opens Office Web Viewer, which is exactly what you don't want).

2. Dokan callbacks are synchronous from the kernel. FindFilesWithPattern enters synchronously, anything that blocks in there hangs Explorer. The first version called Graph synchronously during folder enumeration via .GetAwaiter().GetResult() (I know, I know). Worked fine until Graph went into 429 cooldown, at which point opening a folder hung Explorer for ten minutes. I learned a lot in those ten minutes about how Explorer's UI thread feels under those conditions. Current behaviour: if Graph is in cooldown, folder browse returns immediately with on-disk placeholders, file hydration kicks off via Task.Run, returns a 0-byte placeholder until cooldown lifts.

3. WAM broker fallback when client_id is invalid. Initialise MSAL with WithBroker(brokerOptions) and pass a bogus client_id (e.g. the placeholder GUIDs shipped in config.json that admins are supposed to replace), WAM can't complete the broker handoff and silently falls back to the system browser. User then sees an AAD error page (AADSTS700038) with no link back to "your config.json wasn't filled in". Fixed in 1.3.3 by validating config GUIDs at load time and popping an explicit dialog before MSAL ever runs. Should have done that from day one.

https://github.com/madeyouclickstudio/OneSync

Open to any feedback. Honest caveat: dogfooding with a handful of users, not a full estate, so the load-handling code is engineered but not yet load-tested. Anyone wanting to throw a real workload at it would teach me a lot.

Disclosure first because the mods will catch it: I wrote this, MIT licence, link at the bottom, no upsell.

School IT background, but the use case generalises to any small-to-mid-size M365 estate (schools, small businesses, charities, roughly 20-500 users) wanting proper drive-letter mapping for OneDrive and SharePoint where the OneDrive sync client isn't the right shape. Wanted a drive-letter sync setup with a few specific things: image thumbnails that actually render in Explorer for cloud-mounted files (most existing tools don't), accurate cloud-quota numbers in the drive-properties dialog (refreshed from Graph), a local-first design where files always exist as real NTFS first and sync to the cloud in the background (rather than presenting the cloud as a virtual filesystem), one config.json that deploys to the whole estate, and zero telemetry. Didn't find one off the shelf with all of those, and was also curious whether I could build it myself. Side project that turned into a real thing.

It's called OneSync. .NET 8, Dokan for the FS bridge, MSAL + Graph SDK for auth and sync. Self-contained exe, Intune-deployable.

Highlights:

- True drive letters via Dokan (not subst, not "OneDrive sidebar entry under TenantName - LibraryName")
- One config.json deploys to the whole estate. OneSync probes Graph at startup and silently skips drives the signed-in user can't access, so different roles (staff/students, sales/finance/ops, whatever your split is) share one config
- Accurate cloud quota shown in Explorer drive properties (refreshed from Graph)
- Image thumbnails (JPG/PNG/HEIC) render like a local disk
- LRU eviction below a free-space threshold so shared/hot-desk laptops don't fill up over time
- Office desktop AutoSave + co-auth on docx/xlsx/pptx (via file-association redirect to ms-word:ofe with the direct SharePoint URL, slightly cursed but works)
- Zero telemetry. No analytics, no licence-server pings, no anonymous usage stats. Only outbound calls are to graph.microsoft.com and login.microsoftonline.com.

One war story while I'm here: Dokan's FindFiles callback enters synchronously from the kernel, so anything that blocks in there hangs Explorer. The first version called Graph synchronously to enumerate folders via .GetAwaiter().GetResult() (I know, I know). Worked fine until Graph went into 429 cooldown, at which point opening a folder hung Explorer for ten minutes while the cooldown lifted. I learned a lot in those ten minutes about how Explorer's UI thread feels under those conditions. Current behaviour: if Graph is in cooldown, folder browse returns immediately with on-disk placeholders and file hydration kicks off via Task.Run. Obvious in hindsight.

Repo: https://github.com/madeyouclickstudio/OneSync (DEPLOYMENT.md covers silent install switches and Intune detection rules)

Honest caveat: I'm running it with a handful of pilot users, not a full estate. The fleet-scale stuff is engineered for it but not battle-tested. Anyone deploying this to thousands of users is a pioneer at their own risk. Bug reports very welcome.

Yes I know about the OneDrive sync client. We tried it. The reasons it didn't fit (no real drive letters, every library is its own sidebar entry, no way to cap disk usage on shared laptops, no central deployment for which libraries each user sees) are exactly the reasons this exists. If those don't bother your fleet, OneDrive sync client is fine and you should ignore me.

Tell me what's wrong with it.