15

I’m completely stuck with a folder on Windows 11 that refuses to be deleted. Here’s the situation:

  • Folder path: C:\dev\target_cursed

  • This folder was generated by a bug in a VSCode GitLab plugin, creating thousands/millions (billions ??) of nested folders recursively.

  • I tried those deletion methods (via ChatGPT):

    • rd /s /q "\\?\C:\dev\target_cursed" from CMD (Admin)
    • Remove-Item -LiteralPath "\\?\C:\dev\target_cursed" -Recurse -Force from PowerShell (Admin)
    • Attempting robocopy mirroring an empty folder into it
    • rimraf target_cursed with rimraf

  • No error messages appear in some cases, but the folder remains. In other cases, operations fail silently or hang indefinitely.

I need a method to delete this folder completely without enumerating each subfolder individually (because it will take forever and crash Windows).

Here is the infamous folder:

infinite recursion

Improve this question
4
  • It may be possible to use an alternative .NET assembly. This one is a replacement for Directory.Delete stackoverflow.com/questions/45014914/… powershellgallery.com/packages/PSAlphaFS/2.0.0.1 Commented Oct 1 at 19:09
  • 4
    I wonder if booting into a linux livecd, mounting the drive and deleting it from there would be an option Commented Oct 2 at 1:15
  • 5
    Is this just an extremely deep folder-structure or does it loop back onto itself? If the later your file-system is badly corrupt. Create a new file in 1 of the folders and see it it also appears in the same folder a level up or down. If it does you have corruption. You MUST do a full "chkdsk /F /X" on that drive. If chkdsk can't fix it (check the WIndows Eventlog after the run to see the details) the ONLY remedy is to re-format that filesystem. Commented Oct 2 at 11:11
  • billions ??) of nested folders that is possible, however the primary concern if/when this occurs is the performance impact. A folder is a very small file, and is stored directly in the MFT of the volume. I haven't tested it, but creating one billion folders should add several GB to the MFT, possibly fragmented depending on the fragmentation of the free space. This may result in a volume with poor performance. Commented Oct 2 at 19:13

3 Answers 3

Reset to default
12

There's a very similar question that even mentions that it was caused by a Java based IDE.

The remedy is to use the rm command that ships with Git for Windows, or to write a script that moves the second layer directory to the first, and then deletes the now-empty directory:

cd C:\target_cursed
:LoopStart
move linux\javastics javastics
if errorlevel 1 goto LoopEnd
rd linux
move javastics\app app
if errorlevel 1 goto LoopEnd
rd javastics
move app\linux linux
if errorlevel 1 goto LoopEnd
rd app
goto LoopStart
:LoopEnd
Improve this answer
4
  • 1
    ren linux\javastics javastics doesn't make any sense... you can't move things around with ren, only rename them. Maybe what you wanted was move linux\javastics javastics (or move linux\javastics .)? Commented Oct 1 at 17:14
  • Right, it has been a while since I needed to write a batch script. Commented Oct 1 at 17:27
  • 1
    The link to the question you shared made the difference, especially the part: "Important note: this can take a huge amount of time... Take a break, eat something, drink a coffee, and let the Unix tool do its job ;)" A good rm -rfd target_cursed/ did the job in about forty minutes. The key was patience ;) Thanks! Commented Oct 3 at 8:00
  • You can peel off multiple levels at once, like move linux\javastics\app\linux tmp ; rd linux (recursively remove only 3 levels of directories after you've moved the bulk of it out). See Removing an (apparently) infinitely recursive folder for a Bash example. But yes, +1, peeling off levels from the front instead of descending all the way first should be the most efficient way. Commented Oct 3 at 15:44
6

When you have a path which is too long for Windows to handle, you can use subst to map a drive letter to it and then remove the content from this "drive", thus shortening the path.

As an example, you can do

subst Z: C:\dev\target_cursed\linux\javastics\app\ [go on as much as you can]

Then you'll be able to delete things from Z: without encountering an error.

If the path is still too long after doing this, you can rinse and repeat as you wish, such as

subst Y: Z:\linux\javastics\app\ [etc]
subst X: Y:\linux\javastics\app\ [etc]

until you reach a path Windows is able to manage.

Improve this answer
2
  • 3
    The folder structure in question likely contains tens of thousands, possibly millions of nested directories, which means the “subst drive” approach would reach the alphabet limit long before resolving the problem. I appreciate the suggestion, but unfortunately it doesn’t seem practical for this case. Commented Oct 1 at 13:39
  • 2
    You could actually do this by creating a little batch file that simply alternates between two letters, subst X: Y:\linux\javastics\app\ , subst Y: X:\linux\javastics\app\ , and when the subst fails, delete the tree starting from the one that didn't fail. Unfortunately I don't think you'd be able to step back down the tree using the subst mechanism that way as Windows may refuse to subst Y: X:\..\..\.. so you'd have to start the tree again from the bottom after each deletion, but as it's a batch job you could just leave it running until it's done. Commented Oct 1 at 15:20
2

So, I remember having this problem once twenty years ago with MS-DOS.

My expectation is that cursed/linux/javastics/linux is cursed/linux; that adding a file to one adds it to the other.

In MS-DOS there's no concept of hard-links, but that doesn't mean that the file allocation table or equivalent can't say that the abstract concept of the linux folder exists in the cursed folder and the javastics folder. It shouldn't, it's illegal, but it can.

And you can't get to the end of this infinite recursion because linux always contains javastics which always contains linux.

Windows/Linux are a little more complicated; there are legitimate hard-links (but they're only for files, not folders) and junctions and symbolic links (symlinks) exist which could potentially replicate this behaviour without horrid low-level data corruption. I don't know enough to advise you on how to detect these, but:

https://superuser.com/questions/524669/checking-where-a-symbolic-link-points-at-in-windows-7 claims dir /a will tell you about symlinks, and https://www.computerhope.com/jargon/j/junction.htm agrees for junctions.

If it is corrupted; then this is not a problem caused by the rogue VSCode plugin, but a data integrity problem occurring at a level it should be impossible for application code to cause.

If you really care about the integrity of anything on your system:

  • back-up your data that isn't backed up and don't trust the backups
  • get new physical media
  • restore from backups

If you don't care too much, then run chkdsk, but I would council against using /F initially -- the fix might involve deleting that datastructure, and there may be other issues you weren't aware of. You can probably rename the cursed folder to something else and ignore it and you'll probably be fine (although it might be indicative of some sort of bigger physical problem which might bite you in the end.)

Oh, and I think I had to format that system pretty soon after that bug; I think I tried deleting ../../*, and the .. pointer in linux pointed just fine at cursed, and the .. pointer in cursed pointed just fine at my root directory...

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.