|
Cornelius Henning wrote: check the disk space consumed by Restore Points?
Thanks, that is a great one. Didn't know about it.
I t is only at 3.32 GB at the moment though.
Thanks for the input and ideas on this.
|
|
|
|
|
newton.saber wrote: I was really stumped so I selected all folders on my drive and examined them and it said I had 127GB used. What?
Does it include page file and hibernate file? Guess they are around 32GB in total for your system.
<edit>
Are you logged in with administrator account? Are you sure that your account has permission to all directories?
Also: http://blogs.msdn.com/b/ntdebugging/archive/2008/07/03/ntfs-misreports-free-space.aspx[^]
</edit>
modified 1-Aug-15 19:03pm.
|
|
|
|
|
Mladen Janković wrote: page file and hibernate file?
I was wondering about the page file and wasn't sure.
I do have a hibernate file -- meaning I do use hibernate and i love it --, but that is crazy if it takes like a 100GB or something.
So, let's say that the Hibernate file and the page file are 100GB together, then I'm still missing another 160GB. And if those two files really take up 260GB that is just sick. Sick!
|
|
|
|
|
Volume shadow copies?
Try vssadmin at an elevated prompt.
|
|
|
|
|
dandy72 wrote: vssadmin at an elevated prompt.
Wow, I tried that out. I've been using Windows since version 3.0 and I've never heard of that tool.
I'm sure it wasn't in Windows 3.0 though. 
Anyways, I ran the tool but don't know exactly what it even means.
I guess what I'm learning is :
Windows eats up your hard drive and that is all there is to say about that.j
"All in the name of safety and protection, we've destroyed your life. But, at least the bad guys didn't compromise you." ~The "Good" Guys
|
|
|
|
|
And did you check your privileges? (hehe) I mean for real, file ACLs and stuff.
|
|
|
|
|
I think it was introduced with Vista.
To make a long story short, try:
vssadmin.exe delete shadows /all
...and see if you regain any space.
And as others have written - try windirstat
|
|
|
|
|
Personally I show all files including the hidden and system files on every system I work on.
You could start at the root and work your way from there narrowing down the largest folders off of the root and keep working your way down untill you find the hog.
It is possible that it could be the (Hidden) System restore/ Volume shadow copy folder.
|
|
|
|
|
Try WinDirStat[^]
It's free, and it should tell you what is hogging your drive.
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
|
|
|
|
|
|
|
As I noted in my message right above yours. 
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
|
|
|
|
|
Oopsie! 
|
|
|
|
|
It occurs to me that every algorithm is O(n) for some value n, which may be 2m, m!, m^2, or pretty much anything else, so if I have an algorithm that is O(m!^z), I can simply say that n = m!^z and voila! I have reduced my algorithm to O(n). 
Maybe this will bring Luc back in for a look.
|
|
|
|
|
As long as you're cheating like that, you can also add an arbitrary nesting of logarithms.
|
|
|
|
|
Nesting algorithms are for the birds.
|
|
|
|
|
|
I have the feeling that you are confusing simplifying a problem and solving it...
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
Nah, not really, though I admit that I still don't truly understand Big-O notation.
What got me thinking about this today was the comment:
"If you have figured out the O(n) solution, try coding another solution using the divide and conquer approach, which is more subtle"
Now, I'm pretty sure that the first algorithm to come to mind (and the one I implemented) is not O(n) -- I think it's closer to O(n!) (edit: It isn't; it's O(n^2)) -- so I wonder whether they actually know an O(n) algorithm or maybe they don't understand O(n) notation even as well as I.
From there, it was a simple matter to state that every algorithm is O(n).
modified 2-Aug-15 14:31pm.
|
|
|
|
|
PIEBALDconsult wrote: From there, it was a simple matter to state that every algorithm is O(n).
OK.
If you choose the "correct" criterion for measuring the complexity of your problem, then every problem is indeed O(n). For example, in the Travelling Salesman Problem, if you choose "The number of possible paths" as your complexity criterion, then the problem may be seen as O(n).
Most of us would choose "The number of stops on the route" to be a more useful complexity criterion, which makes the solution to the problem of much higher complexity.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
The maximum subarray thing? Obviously O(n) operations (with n being the size of the array), with Kadane's algorithm. Or O(n2) by just trying everything. O(n!) .. then you're doing something weird.
I don't know wtf they're talking about with their divide and conquer, it doesn't get any better than Kadane's.
|
|
|
|
|
harold aptroot wrote: The maximum subarray thing?
Yes, shhhh... I didn't want to make this a programming discussion.
Thanks for pointing me to Kadane's algorithm -- I didn't know about it and I see that it is indeed O(n). My implementation is ummm... not. 
But then, the OP was given a more complex problem to solve anyway.
So I didn't get to O(n), but I got some good exercise in C and that's what I wanted.
And I implemented the "larger" problem of being able to tell you exactly which members of the array are involved in the greatest (and longest) subarray sum.
I don't think it's O(n^2) and I suppose I shouldn't have said O(n!). I think it's more like O(1+2+...n), but there's no name for that is there?
I'll continue to think about it and maybe there is an actual O(n) algorithm for this.
harold aptroot wrote: wtf they're talking about with their divide and conquer
I suspect that a shark has been jumped. The code complexity would far outweigh the problem complexity.
|
|
|
|
|
PIEBALDconsult wrote: I think it's more like O(1+2+...n), but there's no name for that is there?
You're absolutely right it would be that funny sum. But actually.. that would be O(n2)
Follows from the old "sum of 1 to n = n(n+1)/2" thing, and n(n+1)/2 is less than 2n2 for all n>0 so it's in O(n2)
edit: actually wait, I'm starting to doubt it would be that sum in the first place. No matter though, enumerating all the subarrays is going to be O(n2) anyway.
|
|
|
|
|
I can see that, thanks.
So the algorithm I implemented is O(n<sup>2</sup>) (at worst) and I added some improvement that should usually reduce the actual effort required.
|
|
|
|
|
harold aptroot wrote: I'm starting to doubt it would be that sum in the first place
Hope I didn't ruin your Sunday.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
