delete recursive directory created by robocopy when "The file name is too long"

Question

After running robocopy.exe to backup a C:\Users\ folder without using the /xj switch, I ended up with a recursive directory which was too long. For example, if you run dir /b /s you will receive the following error:

The directory name C:\Users\ ... \AppData\Local\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data is too long.

I tried deleting it with rmdir "Application Data" /s but I received the error "The file name is too long"

I've looked at other solutions, but I thought I might be able to use the tool that caused the issue to solve it.

Answer 1

Create an empty directory with mkdir empty, then use robocopy empty\ "Application Data\" /mir" which will remove the whole directory tree. Then issue a rmdir empty and rmdir "Application Data to clean up and you're done.

Answer 2

You may be able to cd down deep enough into the directory to delete what's below and cd back up to the top again and delete what's left.

If that doesn't work and you're still stuck, download the free demo version of my Hamilton C shell (full disclosure: I'm the author) and use the rm utility that comes with it using the -r (recursive) and -x (delete anything) options.

rm -rx directoryname

My rm uses the new long Unicode filename format internally, allowing it to manipulate paths up 32K characters, and that should get it.

If you discover the problem also involves permissions, you may need to use sudo or su to elevate, e.g.,

sudo rm -rx directoryname

In really stubborn cases, you may be stymied by an ACL that prevents access, e.g.., cacls reports Everyone:(DENY). In that case you may need to remove that ACE (access control entry).

cacls directoryname /e /r everyone

Finally, I really intend for this to be helpful. My server logs tell me people are downloading my software to try this and I want this to work. If you encounter a case where it didn't, I hope you'll reach out to tell me so I can debug why and make it work. Stuff you can't delete happens a lot and I'd like to have all the cases covered.

Answer 3

You could also try one of the following;

Resolution 1: Use an auto-generated 8.3 name to access the file

Resolution 2: Rename or move a deep folder

Resolution 3: Map a drive to a folder in the structure of the path Map a drive to a folder inside the structure of the path of the target file or folder. This method shortens the virtual path.

Resolution 4: Use a network share that is as deep as the folder If Resolution 1, 2, and 3 are not convenient or do not resolve the issue, create a network share that is as deep in the folder tree as you can, and then rename the folders by accessing the share.

Resolution 5: Use a tool that can traverse deep paths

http://support.microsoft.com/kb/320081