Comment by ggm

1 month ago

The thread on reddit is hilarious for the lack of sympathy. Basically, it seems to have come down to commanding a deletion of a "directory with space in the name" but without quoting which made the command hunt for the word match ending space which was regrettably, the D:\ component of the name, and the specific deletion commanded the equivalent of UNIX rm -rf

The number of people who said "for safety's sake, never name directories with spaces" is high. They may be right. I tend to think thats more honoured in the breach than the observance, judging by what I see windows users type in re-naming events for "New Folder" (which btw, has a space in its name)

The other observations included making sure your deletion command used a trashbin and didn't have a bypass option so you could recover from this kind of thing.

I tend to think giving a remote party, soft or wet ware control over your command prompt inherently comes with risks.

Friends don't let friends run shar files as superuser.

I understood Windows named some of the most important directories with spaces, then special characters in the name so that 3rd party applications would be absolutely sure to support them.

"Program Files" and "Program Files (x86)" aren't there just because Microsoft has an inability to pick snappy names.

  • Fun fact: that's not true for all Windows localizations. For example, it's called "Programmi" (one word) in Italian.

    Renaming system folders depending on the user's language also seems like a smart way to force developers to use dynamic references such as %ProgramFiles% instead of hard-coded paths (but some random programs will spuriously install things in "C:\Program Files" anyway).

    • The folders actually have the English name in all languages. It's just explorer.exe that uses the desktop.ini inside those folders to display a localized name. When using the CLI, you can see that.

      At least it's like that since Windows 7. In windows XP, it actually used the localized names on disk.

  • You forgot the wonderful "Documents and Settings" folder.

    Thank god they came to their senses and changed it to "Users", something every other OS has used for forever.

  • Should have called it Progrämmchen, to also include umlauts Ü

    • When I was at Microsoft, one test pass used pseudolocale (ps-PS IIRC) to catch all different weird things so this should have Just Worked (TM), but I was in Windows Server team so client SKUs may have been tested differently. Unfortunately I don't remember how Program Files were called in that locale and my Google-fu is failing me now.

      3 replies →

  • Microsoft is hilariously bad at naming things

    • Visual Studio Code has absolutely nothing to do with Visual Studio. Both are used to edit code.

      .NET Core is a ground up rewrite of .NET and was released alongside the original .NET, which was renamed .NET Framework to distinguish it. Both can be equally considered to be "frameworks" and "core" to things. They then renamed .NET Core to .NET.

      And there's the name .NET itself, which has never made an iota of sense, and the obsession they had with sticking .NET on the end of every product name for a while.

      I don't know how they named these things, but I like to imagine they have a department dedicated to it that is filled with wild eyed lunatics who want to see the world burn, or at least mill about in confusion.

      4 replies →

    • Java and Javascript would like to have a chat :)

      --

      But Copilot is another Microsoft monstrosity. There's the M365 Copilot, which is different from Github Copilot which is different from the CLI Copilot which is a bit different from the VSCode Copilot. I think I might have missed a few copilots?

      2 replies →

> it seems to have come down to commanding a deletion of a "directory with space in the name" but without quoting which made the command hunt for the word match ending space which was regrettably, the D:\ component of the name, and the specific deletion commanded the equivalent of UNIX rm -rf

I tried looking for what made the LLM generate a command to wipe the guy's D drive, but the space problem seems to be what the LLM concluded so that's basically meaningless. The guy is asking leading questions so of course the LLM is going to find some kind of fault, whether it's correct or not, the LLM wants to be rewarded for complying with the user's prompt.

Without the transcription of the actual delete event (rather than an LLM recapping its own output) we'll probably never know for sure what step made the LLM purge the guy's files.

Looking at the comments and prompts, it looks like running "npm start dev" was too complicated a step for him. With that little command line experience, a catastrophic failure like this was inevitable, but I'm surprised how far he got with his vibe coded app before it all collapsed.

  • > which made the command hunt for the word match ending space which was regrettably, the D:\

    Is this even how the delete command would work in that situation?

    >rmdir /s /q D:\ETSY 2025\Antigravity Projects\Image Selector\client\node_modules.vite

    like wouldn't it just say "Folder D:\ETSY not found" rather than delete the parent folder

    • LLM there generates fake analysis for cynically simulated compliance. The reality is that it was told to run commands and just made a mistake. Dude guilt trips the AI by asking about permission.

      1 reply →

    • Most dramatic stories on Reddit should be taken with a pinch of salt at least... LLM deleting a drive and the user just calmly asking it about that - maybe a lot more.

    • It probably wasn't the rmdir command that deleted the parent folder by itself, but the LLM did the traversal. The LLM probably did this:

          rmdir D:\dir one\dir two\file
      

      Detected that it failed, then the LLM issued the traversal command

          rmdir D:\dir one\dir two
      

      And so on...

          rmdir D:\dir one
      

      And then that failed, so...

          rmdir D:\

  • Tens of thousands of novices have failed to run npm dev, yet didn't accidentally delete their hard drive.

> but without quoting which made the command hunt for the word match ending space which was regrettably, the D:\ component of the name

Except the folder name did not start with a space. In an unquoted D:\Hello World, the command would match D:\Hello, not D:\ and D:\Hello would not delete the entire drive. How does AI even handle filepaths? Does it have a way to keep track of data that doesn't match a token or is it splitting the path into tokens and throwing everything unknown away?

  • We're all groping around in the dark here, but something that could have happened is a tokenizer artifact.

    The vocabularies I've seen tend to prefer tokens that start with a space. It feels somewhat plausible to me that an LLM sampling would "accidentally" pick the " Hello" token over the "Hello" token, leading to D:\ Hello in the command. And then that gets parsed as deleting the drive.

    I've seen similar issues in GitHub Copilot where it tried to generate field accessors and ended up producing an unidiomatic "base.foo. bar" with an extra space in there.

  • I assumed he had a folder that started with a space at the start of the name. Amusingly I just tried this and with Windows 11 explorer will just silently discard a space if you add it at the beginning of the folder name. You need to use cli mkdir " test" to actually get a space in the name.

Please don't repeat some guy's guess about spaces as fact, especially when that's not how windows parses paths.

  • A good point. And don't believe how the debug the AI system produced relates to what it did either.

I have 30 years experience working with computers and I get nervous running a three line bash script I wrote as root. How on earth people hook up LLMs to their command line and sleep at night is beyond my understanding.

> I tend to think giving a remote party control over your command prompt inherently comes with risks.

I thought cursor (and probably most other) AI IDEs have this capability too? (source: I see cursor executing code via command line frequently in my day to day work).

I've always assumed the protection against this type of mishap is statistical improbability - i.e. it's not impossible for Cursor to delete your project/hard disk, it's just statistically improbable unless the prompt was unfortunately worded to coincidentally have a double meaning (with the second, unintended interpretation being a harmful/irreversible) or the IDE simply makes a mistake that leads to disaster, which is also possible but sufficiently improbable to justify the risk.

A lot of 3rd party software handle space, or special characters wrong on Windows. The most common failure mode is to unnecessarily escape characters that don't need to be escaped.

Chrome's Dev Tool (Network)'s "copy curl command (cmd)" did (does?) this.

There is bunch of VS Code bug is also related to this (e.g. https://github.com/microsoft/vscode/issues/248435, still not fixed)

It's also funny because VS Code is a Microsoft product.

> Basically, it seems to have come down to commanding a deletion of a "directory with space in the name" but without quoting which made the command hunt for the word match ending space which was regrettably, the D:\ component of the name, and the specific deletion commanded the equivalent of UNIX rm -rf

More like the equivalent of "rm -rf --no-preserve-root".

This is a rare example of where the Linux (it's not Unix and almost no-one uses Unix anymore) command is more cautious than the Windows one, whereas it's usually the Linux commands that just do exactly what you specify even if it's stupid.

This is Google moving fast and breaking things.

This is a Google we've never seen before.