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.
And then half of your programs would be in "Program Files" because those people never knew windows had localizations.
1 reply →
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 Ü
A lot of programs break on Polish computers when you name your user "Użytkownik". Android studio and some compiler tools for example.
5 replies →
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 →
user: How do I shutdown this computer?
tech: First, click on the "Start" button...
user: No! I want to shut it down
2 replies →
I remember they prepended the word “Microsoft” to official names of all their software.
4 replies →
TIL it was deliberate!
> 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:
Detected that it failed, then the LLM issued the traversal command
And so on...
And then that failed, so...
I would like to know the same thing. Can someone please confirm this?
2 replies →
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.
I only run ai tools in dev containers, so blast radius is somewhat minimal.
I don't think I've ever seen Claude even ask for permission for stuff outside of the directory it's working in
That can happen if Claude decides to read source code for a dependency (depending on language; e.g. Rust/Go/Deno deps are under ~ not in something like ./node_modules).
I run Codex in a sandbox locked to the directory it is working in.
umm, you have backups, right?
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.
> My view is that the approach to building technology which is embodied by move fast and break things is exactly what we should not be doing because you can't afford to break things and then fix them afterwards.
- Demis Hassabis "The Thinking Game"
You can afford to break a large variety of things. And you can't afford to break another large set.
That's the problem with those mindless advice pieces. Almost nothing is always right or wrong.
2 replies →
Because... they normally move slowly and break things?
The "move fast" bit, not "break things" bit.
https://www.spiceworks.com/tech/data-management/news/google-...
https://www.itbrew.com/stories/2024/05/23/google-cloud-accid...
isn't antigravity the windsurf team?