In bug 666611 we landed a change that uses GetDiskSpaceAvailable to check the available disk space for the profile. A test leveraging this code is permaorange on Windows, while passes on other platforms, it is constantly detecting less than 100MB of disk space avaible on Windows. Any idea if there is some sort of quota or what else? Doesn't seem dependent on the specific slave. http://tinderbox.mozilla.org/showlog.cgi?log=Mozilla-Inbound/1312457766.1312461106.26374.gz http://tinderbox.mozilla.org/showlog.cgi?log=Mozilla-Inbound/1312457770.1312460196.21923.gz http://tinderbox.mozilla.org/showlog.cgi?log=Mozilla-Inbound/1312455870.1312459293.16844.gz http://tinderbox.mozilla.org/showlog.cgi?log=Mozilla-Inbound/1312455872.1312458541.11977.gz http://tinderbox.mozilla.org/showlog.cgi?log=Mozilla-Inbound/1312455235.1312458442.11624.gz http://tinderbox.mozilla.org/showlog.cgi?log=Mozilla-Inbound/1312455237.1312457870.8645.gz

Those logs are both XP and Win7 slaves. Spot checking a few of them: talos-r3-xp-005 - 119G free talos-r3-xp-018 - 84G free talos-r3-w7-004 - 129G free talos-r3-w7-006 - 110G free on the C:\ drive, which is the only partition in use. I don't think we have any quotas set up, and it seems extremely unlikely we'd be using so much swap as to exhaust all that space. Could nsLocalFile::GetDiskSpaceAvailable be incorrect on windows ?

It's practically just an alias for ::GetDiskFreeSpaceExW winapi call, that is the size of the largest file that may be created by the user owning the current thread. It's unlikely that winapi is that wrong, especially since it reports correct size on our boxes. Sure it's possible there is another bug somewhere we are missing, no doubt. This works on my Windows boxes (reports about 700GB free): Components.utils.import("resource://gre/modules/Services.jsm"); var profile = Services.dirsvc.get("ProfD", Components.interfaces.nsILocalFile); profile.diskSpaceAvailable; may you please try it on a slave like those ones with the same user that would run the tests?

talos-r3-w7-021: js returns 116794798080, Windows Explorer says 108GB free talos-r3-xp-028: js returns 91731361792, Windows Explorer says 85GB free

Those were both using the Error Console in an opt browser, rather than a debug xpcshell like the log failures. Might be worth taking a look at [1] to see how it creates a profile for xpcshell to run against. [1] http://mxr.mozilla.org/mozilla-central/source/testing/xpcshell/runxpcshelltests.py

actually, I was debugging another bug today, and looks like ::GetDiskFreeSpaceExW fails, and when that happens GetDiskSpaceAvailable magically returns 0. So it's possible we are hitting a similar problem. I'm still investigating why it may fail.

Using it on the database file fails, while using it on the profile dir works. Interesting since the above example used ProfD Indeed this returns 0, looks like on Windows diskSpaceAvilable can only be used on folders: Components.utils.import("resource://gre/modules/Services.jsm"); var file = Services.dirsvc.get("ProfD", Components.interfaces.nsILocalFile); file.append("places.sqlite"); file.diskSpaceAvailable;

resolving, I've filed bug 681660 on the underlying bug.