As someone who recently managed to accidentally sync to his machine all several million files in our entire source tree (all source to all release branches), I found that the fastest way to delete a directory with too many files is to use robocopy and copy a directory containing one file to the directory you want to delete with the /MIR flag.
This was many orders of magnitude faster than the command line or explorer (the latter took four hours just to create the index of the files it wanted to delete). On Thu, Feb 19, 2009 at 3:37 PM, Erik Kay <[email protected]> wrote: > > Wow. That's really cool. The slow solution load time has been really > pissing me off for a while now. Emptying this directory fixed this > problem completely for me. I recommend everyone do this. > > The wacky bit about that directory is that (for me at least) it's a > bunch (31000+) of empty directories. Just opening the directory up to > look at it took almost 10 minutes for me. Someone on the net said it > took him two hours to delete the files. I recommend that you do it > from the command-line. > > I did some searching using my favorite search engine and found the > following tidbit: > === > http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=347228 > Our problem is that developers are accumulating massive numbers of > directories and files (24,000+ directories in one case) in the > %userroot%\Local Settings\ApplicationData\Microsoft\WebSiteCache > directory. Our solutions tend to have upward of 150-200 projects so > this is a real problem. We are also seeing the following unnecessary > lines (for windows apps!) in our .sln files that seem to be causing > the issue: > ProjectSection(WebsiteProperties) = preProject > Debug.AspNetCompiler.Debug = "True" > Release.AspNetCompiler.Debug = "False" > EndProjectSection > === > > Apparently, the unnecessary insertion of these lines is a known bug in > VS2005 that's fixed in VS2008. Maybe the new solution/project > generator will solve this for us by omitting these lines from the sln. > > Erik > > > On Thu, Feb 19, 2009 at 2:41 PM, Eric Roman <[email protected]> wrote: >> >> So I recently had the problem where loading "chrome.sln: takes about >> 10 minutes (in other words, absurdly long). >> >> It seems this time the the problem was VS trying to load many hundreds >> of hundreds of files from "~/Local Settings/Application >> Data/Microsoft/WebsiteCache/*" >> Not sure why that happened, but deleting "WebsiteCache" did help >> dramatically. >> >> Since super slow load times is a regular problem for me, I am >> wandering what workarounds others have. >> >> One thing I find myself frequently doing is to delete the "chrome.ncb" >> and build output directories. This usually shaves off a couple minutes >> for me, and is marginally less disruptive to rebuild than be stuck >> waiting for the project to load. >> >> Thanks! >> >> > >> > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
