[jmiddel]

Startup HD > GET INFO shows twice the size of what it was yesterday. The backup HD from 12 hours ago still shows the right amount, I cannot find the extra stuff on the HD, the sum of the APP folder plus users and everything else on the drive is what it should be yet the drive as a whole is literally 2x bigger. The only system relevant thing I did was to install (not run) the upgrade to TechToolPro, as I have a new iMac, up from a G5 PM. I have done: restart, safe restart, single user with fsck, Diskwarrior, I then launched TechToolPro and it also found no problem. So where is the extra data if there is any,and how do I fix this weird problem? Thanks!

[turtle777]

When restarting, some virtual memory gets cleared out and HD space increases.

But it wouldn't double the HD space.

-t

[reader50]

I think he means the used space doubled.

Run OmniDiskSweeper. It could be VM, but is more likely a runaway logging process. Possibly hiding in an invisible folder. OmniDiskSweeper shows all files & folders, sorted by size. Follow the big space usage near the top.

[angelmb]

Has TechTool Pro created an eDrive (emergency drive) for you?

[jmiddel]

Hi reader50, I just ran Omnisweeper, everything looks normal, no huge files. In fact in its menu bar the HD is listed as the correct amount.

angemb, no TTP did not create the emergency drive.

Also, TTP reads the drive size same as Get Info, as opposed to Omnisweeper

Thanks

[reader50]

Could you post a few screen shots, to illustrate the problem? ie:

The Get Info window that shows the suspect value.
Disk Utility info on the drive.
TTP info on the drive.
OmniDiskSweeper sweep window for the drive.

[Ω]

Originally Posted by reader50 

I think he means the used space doubled.

Run OmniDiskSweeper. It could be VM, but is more likely a runaway logging process. Possibly hiding in an invisible folder. OmniDiskSweeper shows all files & folders, sorted by size. Follow the big space usage near the top.

Put a dollar on a runaway log.

[jmiddel]

Ω, there is no runaway log, omnisweeper woud show that, also nothing in Top suggests it, moreover the HD is steady at double, has not increased in the last 24 hours. It's almost as if somehow a glitch simply multiplied the Gigs by 2, so it comes up this way in apps like Get Info that read the disk volume header or such, while omnisweeper, which deals with the actual files, gives the correct result, as does my summation of the actual folders on the volume.

reader50, I have the screen shots, and am trying to upload them, it's tedious because I have to eneter the entire path, I can't just browse to get them, which seems to me to be so much easier I don't understand why this site does not allow that.

[turtle777]

Originally Posted by jmiddel 

reader50, I have the screen shots, and am trying to upload them, it's tedious because I have to eneter the entire path, I can't just browse to get them, which seems to me to be so much easier I don't understand why this site does not allow that.

Use photobucket.com or the likes.

-t

[jmiddel]

Thank you turtle, here is the link to the screenshots on photobucket: Pictures by jmiddel - Photobucket

[AKcrab]

You're saying that the drive in question is NOT a 1TB drive, but a 500GB drive??

[reader50]

jmiddel, thanks for the pictures. And they're enough to give the solution. The 180 GB of 'missing' files are in a folder your user account doesn't have permission to access. No real idea where that would be. Maybe something system-related, maybe other user accounts.

Log into the root user account, and run OmniDiskSweeper from there. It will be able to see the entire file tree, and will show you where the missing 180 GB went to.

[chabig]

You might have a directory problem. You said you had a full backup. I'd probably just reformat the drive and restore from backup.

[reader50]

AKcrab, he's referring to the used space discrepancy. Disk utilities say 421 GB are used on the Jan 1 drive. But adding up the folder sizes in the Finder comes to 245 GB, and OmniDiskSweeper adds the volume up to the same total.

[AKcrab]

I see.. I would certainly trust disk utility to be the "right" information.

Nobody has thrown out Repair Permissions yet. Can't hurt.

OmniDiskSweeper won't go in my toolkit if it doesn't ignore permissions when it scans. (Running it as root will certainly fix that though.)

[chabig]

Nobody has mentioned Repair Permissions because this doesn't look to be a permissions issue. I might try Repair Disk, but it'd be safer to reformat and restore.

[Art Vandelay]

Originally Posted by reader50 

jmiddel, thanks for the pictures. And they're enough to give the solution. The 180 GB of 'missing' files are in a folder your user account doesn't have permission to access. No real idea where that would be. Maybe something system-related, maybe other user accounts.

Log into the root user account, and run OmniDiskSweeper from there. It will be able to see the entire file tree, and will show you where the missing 180 GB went to.

That's definitely the problem. I thought ODS used to require authentication so it ran with root privileges so it can scan everything. Not being able to scan everything seems to negate its effectiveness.

[AKcrab]

Originally Posted by chabig 

Nobody has mentioned Repair Permissions because this doesn't look to be a permissions issue. I might try Repair Disk, but it'd be safer to reformat and restore.

Originally Posted by reader50 

The 180 GB of 'missing' files are in a folder your user account doesn't have permission to access. No real idea where that would be. Maybe something system-related, maybe other user accounts.

That certainly sounds permission related to me. The question would be if repairing them would even touch the files that are not showing up. Will it fix anything? Maybe not, but it can't hurt.

[ghporter]

Originally Posted by AKcrab 

That certainly sounds permission related to me. The question would be if repairing them would even touch the files that are not showing up. Will it fix anything? Maybe not, but it can't hurt.

The "problem" isn't permission related, but the reason the guy can't see the missing space is. What's causing that space to be put where he can't see it is an issue.

[jmiddel]

OK, I booted from BU disk, repaired permissions, still can't see the rogue file. Ran TTP and DW rebuilds, nothing, no errors. Re-installed the combo and a firmware update, no change. I cannot get into root, when I try to to enable root in the Directory Utility I can do so, but I can't add a new user as root in Accounts. Also, when I try to run /ls -a, or sudo / ls -a I get a permission denial. So I can't run the diagnostic that reader50 recommends, running omnisweeper as root. I am logged in as admin.

ghporter you hit the nail on head, why, and what, is hiding this space on the HD?! I don't run any security apps other than the native OS ones, and have nothing special enabled, just the basic firewall.

[reader50]

root does not show in Accounts. Once it's enabled, you can log into it. From the Login pane, select the "Other..." option. That will bring you to the text login. Put in "root" and whatever password you specified for it.

[jmiddel]

reader50, you did it!! Running omnisweeper as root, it found the culprit: Volumes. There are 197.2 G of Volumes. The biggest Volume is a BU disk that is not even attached to the computer. The volume sizes, also, are quite divergent from the actual drives, smaller. So, how do I unmount these volumes, and how might they have stuck around after one of my nightly BUs using SuperDuper? I have been doing this for many years without a glitch. All my apps are up to date. Thank you much, reader50.

[reader50]

/Volumes is a mounting point - it normally contains only aliases. Sounds like the backup disk was disconnected - but SuperDuper didn't notice and wrote directly to the /Volumes folder. This isn't supposed to happen, but I've heard of it a few times.

If a disk is not connected, then you can delete it's folder in /Volumes. I'd suggest only doing that with the BU disk, making certain it is not connected for real. You want to clean out the bogus folder, not the real BU disk.

You can delete it from within OmniDiskSweeper. Select the bogus folder, and click the big delete button on lower left of the sweep window.

Edit: when I checked my system with OmniDiskSweeper, my /Volumes entries are normal. The boot volume has a 4KB entry, all the other volume entries show as zero bytes. That's how it is supposed to be.

[besson3c]

OmniDiskSweeper is just a GUI for Unix du... I'm surprised that OmniDiskSweeper doesn't run as root, but if you ever doubt its output you can get the same sort of listing via:

sudo du -sh /

substitute whatever path you want for the slash (the above summarizes disk usage for your entire computer, which would include /Volumes)

[besson3c]

You can also launch an app as root this way:

sudo open /Applications/Yourapp.app

[Art Vandelay]

Originally Posted by besson3c 

You can also launch an app as root this way:

sudo open /Applications/Yourapp.app

I've never seen that work. The app still is owned by the current user. I think all it really does is execute open as root which still tells the current user's LaunchServices to open the app.

[reader50]

sudo /applications/appname.app/Contents/MacOS/appname

example: sudo /applications/calculator.app/Contents/MacOS/calculator

The "Contents/MacOS" part is case-sensitive. The rest isn't.

[jmiddel]

Thank you everyone, especially reader50 who spotted the problem and helped me through this mystery. OmniDiskSweeper easily, albeit lengthily, deleted the volumes, then I booted from external, ran DiskWarrior and all it needed to change was the file size

I will remember the sudo open commands, so useful!