Archive for the ‘SysAdminTools’ Category

findUsedSpace RC6 Released

Monday, September 10th, 2007

Well, turns out I screwed up the build of the last release and it only ran on a 1.6 JVM, and threw a really awesome error on a 1.5 JVM (but only when it started using the Directory class - I have no idea how I managed to screw that up). Glad I tested it thoroughly, eh!

New Release pretty much only fixes this issue, the code is the same underneath. The updated packages for Solaris and Generic OS’ can be found in the files area.

Sorry for any confusion, my bad.

findUsedSpace - Release Candidate 5 Available for Download

Monday, September 3rd, 2007

I have released a bug fixed release of findUsedSpace. This fixes a bug on Solaris 10+ Systems, that contain zones. There was an endless loop when you reached the proc filesystem of a zone, when running from the global.

This RC is likely to have one more minor code clean up before it is released as findUsedSpace 1.0.

There is a feature request for the next release to skip autofs,ctfs,objfs,devfs,dev and any other filesystems on a UNIX (Solaris specifically) platform which isn’t really relevant when you’re trying to figure out what has chewed all the space on a disk.

For those who are unaware what the tool does, it basically allows you to do something very similar to du, by finding how much space a parent directory and all its children are taking up (or a single file), however, it is based on thresholds, and allows you to be very clear on what you are looking for (say, files and directories over 1 gigabyte). It runs at virtually the same speed as native du (tiny little bit slower in my tests, but the difference is negligible).

The other benefit over du is it is pure java, and platform independent. It is tested on Windows and Solaris, but should run on anything. Though written on a 1.6 JVM, it is compiled for a 1.2 JVM, so as even really old systems can run the software.

You can download a Solaris packaged release, or a zip file release from here:

You’ll notice its packaged as AdeptTools (even though it’s just one tool at this point). The idea was/is that I will gradually write more and more code as new problems present themselves to me, and package it as a toolkit. Not sure if it will work out that way in the end, we’ll see. Due to somethings ending up platform dependent, it may end up that each tool is released separately, and as part of a package if you want the lot.