Disk space eaten up!

[kastenbrust]

time machine can use your own hard drive for backups, just check the settings to make sure its not backing up on your own hard drive, theres loads of threads on here where people have that problem.

 

[pinback pro]

shut off time machine, find the files it has backed up, and move them to an external... you are using your boot drive for a backup and that just doesn't work.

 

[virtuosity]

shut off time machine, find the files it has backed up, and move them to an external... you are using your boot drive for a backup and that just doesn't work.

I'm promise you i am not!!

i have an external 500MB drive which time machine is used to back up to - if time machine is using my local hard drive then it isn't working properly - everything i've done to configure it is set to using this external drive.

I've looked into this time machine app a little more, and i've decided that the cost far outweighs the benefit, so i'm gonna ditch it and just perform manual backups of my named folder (most importantly my iPhoto albums and iTunes library) onto my storage device

so i have switched it off in the meantime, but question is - how do i find out if time machine has been using my local hard drive for backup storage, and if so - how do i find the file(s) and delete it (them)?? does anyone know pls?

I have tried looking through my hard drive and through these forums but i cannot see anything - but will keep looking...

 

[bplein]

Disk Inventory X is a great free tool for discovering what's eating up your drive space.

 

[BlueRevolution]

Are there any directories in the root of your drive besides Applications, Library, System, and Users? If so, try doing get info on them. If not, do get info on all visible directories. It'll take a very long time, but you'll be able to compare its results with the total used space on your drive and determine whether your problem file(s) is/are visible or invisible.

 

[virtuosity]

Are there any directories in the root of your drive besides Applications, Library, System, and Users? If so, try doing get info on them. If not, do get info on all visible directories. It'll take a very long time, but you'll be able to compare its results with the total used space on your drive and determine whether your problem file(s) is/are visible or invisible.

well, thanks Blue!!! Looks like your suggestion did the trick...

I have discovered several asl files in the path private > var > log > asl that are several GB's in size. Having done some very quick investigation into this, it would appear to be a common problem - relating to error log files...

apparently, the solution is to find the rogue application (or whatever it is) that is causing the error, and simply remove it

btw, reminds me of the 1980's Haynes Car Manuals.... "Simply remove clutch."

Anyway - I will dig a little further into this now I have at least found the culprit files (which, incidentally, do not appear in spotlight searches due to them being system files or something) - although I am struggling a little with Console app as I have 4000 events since 01.02.2008!!! - it's running a tad slow....

A BIG THANK YOU to all who helped me with this issue

BlueRevolution - again, great suggestion on the Disk Inventory X app

 

[virtuosity]

It would appear that the rogue application is Azureus/Vuze 4.0.0.4

I have literally thousands of entries of the following:

01/01/2009 20:25:18 [0x0-0x376376].org.gudy.azureus2[7951] java.io.IOException: Host is down
01/01/2009 20:25:18 [0x0-0x376376].org.gudy.azureus2[7951] at java.net.PlainDatagramSocketImpl.send(Native Method)
01/01/2009 20:25:18 [0x0-0x376376].org.gudy.azureus2[7951] at java.net.DatagramSocket.send(DatagramSocket.java:612)
01/01/2009 20:25:18 [0x0-0x376376].org.gudy.azureus2[7951] at com.aelitis.net.udp.uc.impl.PRUDPPacketHandlerImpl.send(PRUDPPacketHandlerImpl.java:1292)
01/01/2009 20:25:18 [0x0-0x376376].org.gudy.azureus2[7951] at com.aelitis.azureus.core.dht.transport.udp.impl.packethandler.DHTUDPPacketHandler.send(DHTUDPPacketHandler.java:250)
01/01/2009 20:25:18 [0x0-0x376376].org.gudy.azureus2[7951] at com.aelitis.azureus.core.dht.transport.udp.impl.DHTTransportUDPImpl.process(DHTTransportUDPImpl.java:3319)
01/01/2009 20:25:18 [0x0-0x376376].org.gudy.azureus2[7951] at com.aelitis.azureus.core.dht.transport.udp.impl.packethandler.DHTUDPPacketHandler.receive(DHTUDPPacketHandler.java:290)
01/01/2009 20:25:18 [0x0-0x376376].org.gudy.azureus2[7951] at com.aelitis.azureus.core.dht.transport.udp.impl.packethandler.DHTUDPPacketHandlerFactory.process(DHTUDPPacketHandlerFactory.java:176)
01/01/2009 20:25:18 [0x0-0x376376].org.gudy.azureus2[7951] at com.aelitis.azureus.core.dht.transport.udp.impl.packethandler.DHTUDPPacketNetworkHandler.process(DHTUDPPacketNetworkHandler.java:73)
01/01/2009 20:25:18 [0x0-0x376376].org.gudy.azureus2[7951] at com.aelitis.net.udp.uc.impl.PRUDPPacketHandlerImpl$4.runSupport(PRUDPPacketHandlerImpl.java:767)
01/01/2009 20:25:18 [0x0-0x376376].org.gudy.azureus2[7951] at org.gudy.azureus2.core3.util.AEThread.run(AEThread.java:74)
01/01/2009 20:25:18 [0x0-0x376376].org.gudy.azureus2[7951] [net] PRUDPPacketHandler: send to /94.191.240.54:25645 failed: Host is down

Regardless of whats happening / how / and what's causing this, for now - I am going to try and remove the app and see what happens

 

[gjw4u]

Did they get into a torrent program? Some of them create dummy files that take up the amount of HD space that the completed file would contain.

So miles01110 had the right idea what was causing the problem from the very beginning. Azureus/Vuze = torrent program.

 

[virtuosity]

So miles01110 had the right idea what was causing the problem from the very beginning. Azureus/Vuze = torrent program.

Actually - no. Vuze does appear to be involved in this diagnosis, but with what looks like a java error (either created by the compiler of Vuze in the jar or with java itself) - it looks like it started failing at exactly midnight on 31.12.08 which is a bit strange.... hmm... anyhow...

i am pretty sure I know what miles was alluding to - the way torrent s/w works is if you want to download a 5GB file - it effectively creates a "placeholder" for a 5gb file which is, of course, 5GB in size - even before it's actually, physically downloaded anything. I was aware of this and have seen other people fall at this hurdle so to speak - so like i said earlier in my original post, i had checked the Vuze download folder for any torrents and cleared them out.

The files that were taking up my disk space were actually hidden system error logs created by OSX

 

[BlueRevolution]

BlueRevolution - again, great suggestion on the Disk Inventory X app

Actually, that wasn't me, but you're welcome.

You can specifically disable logging in Vuze by going into Vuze -> Preferences, clicking on the "Logging" page, and unchecking "Enable logging".

Actually - no. Vuze does appear to be involved in this diagnosis, but with what looks like a java error (either created by the compiler of Vuze in the jar or with java itself) - it looks like it started failing at exactly midnight on 31.12.08 which is a bit strange.... hmm... anyhow...

Hmm, if it's a date error, it seems odd that we're not being inundated with people complaining of the same thing right now. Oh well, sounds like it's worked out to everyone's satisfaction.

i am pretty sure I know what miles was alluding to - the way torrent s/w works is if you want to download a 5GB file - it effectively creates a "placeholder" for a 5gb file which is, of course, 5GB in size - even before it's actually, physically downloaded anything. I was aware of this and have seen other people fall at this hurdle so to speak - so like i said earlier in my original post, i had checked the Vuze download folder for any torrents and cleared them out.

Most clients, including Vuze, will only do this if specifically configured to do so. By default, Vuze does not preallocate download space.

 

[virtuosity]

Actually, that wasn't me, but you're welcome.

DOH!!! oh yes! thanks bplein!!!!!

And yes, on your other point re logging - I will try this first to see if it makes any difference... at least i know where to look now in any case!

thanks again!