6 ms·
I was made aware of this artificial limitation through a pretty vivid edge case while I a student some years ago. TortoiseSVN had somehow borked and began to re
by chao- 13y ago
I was made aware of this artificial limitation through a pretty vivid edge case while I a student some years ago. TortoiseSVN had somehow borked and began to recursively create .svn directories inside of each other, as fast as it could, until such time as I managed to kill the process.
Many can guess what happened next: I went to delete the erroneous top-level .svn folder and was given an error, the gist of which was: "Cannot remove. Path too long." There's more to the story, but it turns out the real answer was to boot into a Linux LiveCD and delete from within there.
I found it strange that one set of Win32 calls allowed TortoiseSVN to create paths of a certain depth, but the other set, used by Microsoft in their tools, would not allow me to delete them. These days I understand the reasons behind it, and so instead find it merely annoying.
- cryptos 13y agoSame here, but with Windows' own backup tool.
- fleitz 13y agoThis is only related to the path, if you recursively delete from the top level then it doesn't work, but if you switch CWD to a lower level directory then you can delete the files. eg. rm -rf C:/REALLY/LONG/PATH/ doesn't work but cd REALLY cd LONG rm -rf PATH cd .. rm -rf LONG cd .. rm -rf REALLY works (windows equivalents of course) In past projects I've ended up rewriting most of of System.IO that dealt with paths to fix this issue. Basically all you have to do is prefix your path with \\?\ and voila it works. (Except in .NET which detects you're doing this and stops it)
- VLM 13y agoThis is going to look linux because I don't use windows, but you can automate this by writing two scripts and putting both in your path #!/bin/bash while [ 1 ] do cd .svn done The other looks like this #!/bin/bash while [ 1 ] do cd .. rm -Rf * done Now just run the first until it can't cd any deeper, and then run the second to clean your hard drive very throughly. (note I know darn well what script #2 does ... this would probably make a good debugging question for a sysadmin interview... in case you don't get it, for gods sake don't run script #2 unchanged)
- fleitz 13y agoYou should post both scripts unaltered to stack overflow for the LULZ.
- hobs 13y ago>in case you don't get it, for gods sake don't run script #2 unchanged", fairly harsh... Down voting a guy who does have a warning? However for safety's sake, I would recommend prefacing the code with a warning instead of having it at the end.
- eksith 13y agoActually I saw script #2 on an interview question a little while back (not that the interviewer knew what it did; he didn't seem to have a programming background). Don't exactly recall what the question was, but it was something to the effect of "what are your thoughts on the safety of the following script" or the like. The good thing about nix platforms is that you have nuclear options at your fingertips. The bad thing is that you can't be impulsive or an idiot because you have nuclear options at your fingertips ;)
- VLM 13y agoDitto here, it must have been a management interview fad a decade or two ago. The sysadmin version of fizzbuzz. My particular version was one page script that wiped an existing software installation (and a bit more LOL) and dropped a new version on top of it. The kind of thing that has pretty much been eliminated by using git/etc as a distribution tech and/or puppet. So VLM... nice to meet you, here's the first version of our software upgrade script I was wondering what you'd change. I started laughing, pointed out a few things, he said I passed. It had a lot more wrong with it. Weird quoting mistakes (single vs double, also something along the lines of grep "-R blah blah"). And there were basic conceptual issues, like copying the binaries to /usr/local/bin before replacing the old distribution with the new one, such that you'd get old ones. And the path contained a version number and the script tried to change user PATH env variables ... to the old version path. The proper interview-style fix for my creative solution would be something like rm -Rf .svn instead of rm -Rf *, or bothering to check the output of pwd is longer than X characters using grep -c and some comparisons or playing games with chroot. Its a great interview question because you get a feel for the candidates style, are they most comfortable with chroot, or doing text manipulations of pwd etc or are they a minimalist who likes to make the smallest possible change or into rewriting the whole blasted thing or...
- mzs 13y agoI just googled \\?\ and got no results because google just is that way. Can you explain more about that please.
- dpedigo 13y agoThe following should explain a bit better than I could: http://msdn.microsoft.com/en-us/library/aa365247%28VS.85%29.aspx#maxpath http://msdn.microsoft.com/en-us/library/aa365247%28VS.85%29....
- brutos 13y agoIt's hard to Google, but that syntax is called UNC: http://en.wikipedia.org/wiki/Path_(computing)#Uniform_Naming_Convention http://en.wikipedia.org/wiki/Path_(computing)#Uniform_Naming...
- fleitz 13y agoAs other posters have said it's UNC, however if you're interested in other weirdness around files in Windows, checkout NTFS streams.
- mdmarra 13y agoA UNC always references a network path. You can use \\?\ to reference a network path, but it can also be used to reference a local path too. \\?\ is not always used to represent a UNC. \\?\ is an extended-length path.
- tekacs 13y ago\\?\ is an unparsed path - the path is passed directly to the filesystem, bypassing checks and other Win32 API restrictions - a side effect of this is that maximum length checks are bypassed, but this is NOT the only effect. See GP's link for more details.
- ohaal 13y agoTry symbolhound instead: http://symbolhound.com/?q=%22%5C%5C%3F%5C%22 http://symbolhound.com/?q=%22%5C%5C%3F%5C%22
- badman_ting 13y agoTHIS is what is so crazy-making about this problem. You can keep all your own paths you make intentionally under 260 no problem, but when a piece of code screws up and goes over, it can make your life hell. Over a stupid file. If they're not going to fix the problem, and I respect why they're not going to, at least make it easier to work around. It just seems like on Windows you often have to deal with silly, incredibly annoying problems like this that other platforms don't have.
- qwerta 13y agoNTFS has actual support for hard file links, but only usage I ever seen was for jokes similar to this one.
- justinweiss 13y agoWhen I was still at MS, a lot of these kind of bugs didn't get fixed -- the code checking against the old (smaller) path size would often not be owned by anyone anymore, and nobody wanted to touch it (because that would make them the new owner).
- mdmarra 13y agoIf you ever want to fix an issue like this in the future, it's very easy to just create an empty folder on c:\ named something like "empty" and use robocopy to mirror the empty folder into the folder that is too deep. robocopy c:\empty c:\so_many_subdirectories /mir will do the trick.
- stelonix 13y agoThe same issue happened to me some years ago. The solution to get rid of .svn directories was to use a simple robocopy script I found online (ntfs-3g support for writing was rudimentary back then).
- kijin 13y agoI had a similarly annoying experience, but with Dropbox. On my Ubuntu PC, I created an encrypted folder in my Dropbox using EncFS. Turns out EncFS produces very long folder names and file names if you use the default, most secure setting with per-file IVs. Still, everything worked fine until I booted my Windows PC. As soon as Dropbox started trying to sync with the Windows PC, it ran into the 260-char path length limit and quietly began to truncate their names. Result: corrupted EncFS folder.