676521 - less than 100MB available disk space on Windows test boxes?

Status: RESOLVED INVALID

(Release Engineering :: General, defect)

Description

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

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

Comment 1

[Nick Thomas [:nthomas] (UTC+12)]

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 ?

Comment 2

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

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?

Comment 3

[Nick Thomas [:nthomas] (UTC+12)]

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

Comment 4

[Nick Thomas [:nthomas] (UTC+12)]

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

Comment 5

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

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.

Comment 6

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

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;

Comment 7

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

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