I read over the author's analysis of the `mkdir` error. The author thinks that the abundance of error codes that mkdir can return could've confused gemini, but typically we don't check for every error code, we just compare the exit status with the only code that means "success" i.e. 0.
I'm wondering if the `mkdir ..\anuraag_xyz project` failed because `..` is outside of the gemini sandbox. That _seems_ like it should be very easy to check, but let's be real that this specific failure is such a cool combination of obviously simple condition and really surprising result that maybe having gemini validate that commands take place in its own secure context is actually hard.
Anyone with more gemini experience able to shine a light on what the error actually was?
The problem that the author/LLM suggests happened would have resulted in a file or folder called `anuraag_xyz_project` existing in the desktop (being overwritten many times), but the command output shows no such file. I think that's the smoking gun.
Here's one missing piece - when Gemini ran `move * "..\anuraag_xyz project"` it thought (so did the LLM summary) that this would move all files and folders, but in fact this only moves top-level files, no directories. That's probably why after this command it "unexpectedly" found existing folders still there. That's why it then tries to manually move folders.
If the Gemini CLI was actually running the commands it says it was, then there should have been SOMETHING there at the end of all of that moving.
The Gemini CLI repeatedly insists throughout the conversation that "I can only see and interact with files and folders inside the project directory" (despite its apparent willingness to work around its tools and do otherwise), so I think you may be onto something. Not sure how that result in `move`ing files into the void though.
Yeah, given that after the first move attempt, the only thing left in the original folder was subfolders, (meaning files had been "moved"), the only thing I can think is that "Shell move" must have seen that the target folder was outside of the project folder, so instead of moving them, it deleted them, because "hey at least that's half way to the goal state".
I'm wondering if the `mkdir ..\anuraag_xyz project` failed because `..` is outside of the gemini sandbox. That _seems_ like it should be very easy to check, but let's be real that this specific failure is such a cool combination of obviously simple condition and really surprising result that maybe having gemini validate that commands take place in its own secure context is actually hard.
Anyone with more gemini experience able to shine a light on what the error actually was?