Posted on 2007.08.21 |
Comments (7) |
Windows
This post has been imported from the old blog and has not yet been converted to the new syntax yet.
Long ago, I found something strange in Windows Explorer, which I wanted to retry on Vista today.
In Explorer, first create a very big directory tree, consisting out of small directory names. Now, from the bottom, rename these directories to about 100 characters.
When you reached the top, try browsing the tree, after some directories it won't allow you to open the directory anymore. You can't select it, it will jump back, you can't rename that one, you can't delete the entire tree at once.
You can however to get rid of it, start renaming from the top, to all short names again, until you can delete them.
I realize this has something to do with character limits on paths, but this shouldn't be possible, should it? You can't even delete them properly. Is there a way to prevent this from happening? Or at least be able to clean it up without too much hassle?
I created a small proof of concept, using three .bat files.
Feel free to look at the .bat files with a text editor, to check what it does.
Does anyone know why this is happening? I'd love to know the low-level logic behind this.
In Explorer, first create a very big directory tree, consisting out of small directory names. Now, from the bottom, rename these directories to about 100 characters.
When you reached the top, try browsing the tree, after some directories it won't allow you to open the directory anymore. You can't select it, it will jump back, you can't rename that one, you can't delete the entire tree at once.
You can however to get rid of it, start renaming from the top, to all short names again, until you can delete them.
I realize this has something to do with character limits on paths, but this shouldn't be possible, should it? You can't even delete them properly. Is there a way to prevent this from happening? Or at least be able to clean it up without too much hassle?
I created a small proof of concept, using three .bat files.
- Extract the zip and run Destroy.bat
- It will first call Mtree.bat to make a small directory tree, where all directories are named "1".
- Afterwards it calls calls Rtree.bat to rename the directories to a long name.
Feel free to look at the .bat files with a text editor, to check what it does.
Does anyone know why this is happening? I'd love to know the low-level logic behind this.
+32 (0)478 57.79.17
I don't know exactly what causes it, but I do know that it happens as far back as NT 3.51 (at least that was what I ran when I first found it). Up until vista apparently (according to your post here) you couldn't delete any directory containing a structure like this.
Try this as well:
Create a whole bunch of directories (30 or so)
drag them inside each other to make a tree
copy and paste the directory tree a bunch of times
drag these inside each other
repeat until you have an error message
(error used to appear when directory structure got around 250 levels deep, but I think that was changed in xp)
Now figure out how to delete that directory structure (pre-vista, I think it is impossible, with vista I don't know).
In 2000 you could place files way down in such a directory structure and modify their contents but they wouldn't show up in file searches and you couldn't delete them.
Hi David,
Basically there's one big limitation: MAX_PATH = 260 (see WinDef.h). Nowadays, all file I/O APIs do have a Unicode variant in NT (which requires path names to be prefixed with \\?\) that extends the limit to 2^32 - 1 wchars, where each portion of a path can be up to 2^8 - 1. Nevertheless, the shell and the file system are not sync'd up on various places and the old limit is still recommended to reduce the chance of running into problems; if you really want to write an app that overcomes the old limits, you can use the \\?\ trick but one should be aware that other apps (including Windows Explorer, cmd.exe or backup utilities) might be not be able to see the file because of legacy code.
Btw, the System.IO .NET Framework libs do use the MAX_PATH limitation as well. If you do have the SSCLI 'Rotor' code on your box, take a look at bcl\system\io\path.cs to see how path sanitizing is performed in the BCL.
-Bart
I've hit a similar issue using robocopy when I tried to back up my C drive in Vista. It kept making recursive copies of some of the user settings folders which eventually made the paths very very deep.
I couldn't, for the life of me, find any way to delete the files - which ended up be over 100 GB in size.
Finally I got robocopy to do the work for me and told it to mirror an empty folder to the folder containing my long path files. It worked a treat and cleared the folder out.
I hope that helps.
James.
This problem really exists. I’ve been using the following library that resolves the long filename & path issue. It is not free, but comes with samples and working code. It will help you to solve the problem and save time!
There is no need to rename files or perform any other actions, it just allows to work with files keeping their real long paths, thats all.
Here you will find the tool http://www.abtollc.com/products.aspx
James C-S
Thanks for that tip. Worked out so well.
Renamed the bad directory with more than 100 directories in it to "remove" and made a new directory "blank"
ran robocopy p:\blank p:\remove /MIR
I also got this tree bugg using robocopy to move some files and it went into a loop with the directories.
@James C-S, Kenny
Thanks a lot guys - late and tired last night I managed to make VisualSVN to import an older SVN repository into the same folder, making it go into a loop and create a very long path. The robocopy solution worked like a charm!!!
btw, for anyone interested, the tool is part of the Windows Server 2003 Resource Kit Tools, http://www.microsoft.com/downloads/details.aspx?FamilyID=9D467A69-57FF-4AE7-96EE-B18C4790CFFD&displaylang=en
Kenny said "... it went into a loop ..."
Did Kenny mean, "Robocopy didn't work" ???
After getting down perhaps a hundred levels in the tree I'm trying to delete RoboCopy is still using a lot of CPU but is no longer echoing "extra -1" directories, so it might well be in a loop.
By now the path echoed by RoboCopy fills almost two CMD screens - maybe it just doesn't echo after its stdout buffer fills.
Or Robocopy could be failing.