This 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)
A 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 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.
This 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)
Actually 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 ;)
Ditto 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...
>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.
eg.
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)