No size 'Used Free' information on Desktop Volume Get Info

[grimus]

The boot Volume on the Desktop does not show 'Used/Free' information when 'Get Info' is selected.

The Desktop Icon shows the disk usage scale correctly.

Nightly hrev43955

[anevilyak]

Please provide a screenshot, that information shows in the info window as expected here.

[SeanCollins]

did the volume mount as read/write or read only ? what type of volume is it ? if it is a read only volume, the icon will not indicate disk space.

[grimus]

Sorry, I can see where the screenshot confusion comes from. Grimus IS the boot volume, renamed to try and sort out another problem. Forgot I had done it. Thanks for your responce.

[diver]

I tried to reproduce this bug, but I see another behavior: Capacity string changes to Size: 5 bytes.

[anevilyak]

Will try to find time to look into it sometime in the next days if no one beats me to it.

[grimus]

More information...... Originaly installed onto a Netbook and a Laptop using hrev43955 'anyboot' file download and re-named to iso then burnt image to CD. Both the Netbook and Laptop had the same no 'used free' information when selecting 'get info' on the desktop icon. Running from a live CD gives the same no 'used free' information, which I assume is correct as it is a read only medium. Put a 43990 system folder that was copied from a raw image onto 43955 and the 'used free' information is reported. So it seems the problem is just on installs from CD, or maybe I did something wrong. Sorry for the noise. Closed ?

[anevilyak]

Replying to diver:

I tried to reproduce this bug, but I see another behavior: Capacity string changes to Size: 5 bytes. Restarting Tracker fixes it.

I dug into this one a bit ; before the rename, the stat buffer returned by BEntry::GetStat() tells us that the type is S_IFDIR, which we then correctly promote to the volume type by further checking if it's the root directory. However, if you then rename the volume, a subsequent call to GetStat() on the same entry ref returns S_IFLNK instead, causing Tracker to think you're getting info about a symlink instead. Right now I'm not sure what causes this though, and particularly, why restarting Tracker clears it up. Will try to dig further when I have a bit more time, though if anyone else has some insight here, that would help since I'm not so familiar with the filesystem-related portions of the kernel.