Why does the value from NSFileSystemFreeSize diffe

Question

The following is what I use to get the available storage space on an iOS device for my app:

NSDictionary *dict = [[NSFileManager defaultManager] fileSystemAttributesAtPath:@"/var"];
NSNumber *freeSpace = [dict valueForKey:@"NSFileSystemFreeSize"];

However, the value freeSpace does not correspond with the one shown in the Settings app. The value is always greater than the value shown by Settings. For example, freeSpace is approximately 600,000,000 bytes, where Settings shows 357 MB.

Why is this and how can I get the same value as the value shown by Settings?

Answer 1

I bet that you are using 32-bit integer or float types to store your file system size values. This will fail with large enough file sizes. Instead, use unsigned long long or long double types to store these values.

See the corrected version of this answer for how to read these file sizes accurately. The comments on that answer and others there indicate that this returns a value which matches the free size reported by iTunes and other tools.

Answer 2

Under iOS 11, there are new volume capacity keys that can be passed to URL.resourceValues(forKeys:) that provide values that match what is available in device settings.

• static let volumeAvailableCapacityKey: URLResourceKey Key for the volume’s available capacity in bytes (read-only).

• static let volumeAvailableCapacityForImportantUsageKey: URLResourceKey Key for the volume’s available capacity in bytes for storing important resources (read-only).

• static let volumeAvailableCapacityForOpportunisticUsageKey: URLResourceKey Key for the volume’s available capacity in bytes for storing nonessential resources (read-only).

• static let volumeTotalCapacityKey: URLResourceKey Key for the volume’s total capacity in bytes (read-only).

From Apple's documentation:

Overview

Before you try to store a large amount of data locally, first verify that you have sufficient storage capacity. To get the storage capacity of a volume, you construct a URL (using an instance of URL) that references an object on the volume to be queried, and then query that volume.

Decide Which Query Type to Use

The query type to use depends on what's being stored. If you’re storing data based on a user request or resources the app requires to function properly (for example, a video the user is about to watch or resources that are needed for the next level in a game), query against volumeAvailableCapacityForImportantUsageKey. However, if you’re downloading data in a more predictive manner (for example, downloading a newly available episode of a TV series that the user has been watching recently), query against volumeAvailableCapacityForOpportunisticUsageKey.

Construct a Query

Use this example as a guide to construct your own query:

let fileURL = URL(fileURLWithPath:"/")
do {
    let values = try fileURL.resourceValues(forKeys: [.volumeAvailableCapacityForImportantUsageKey])
    if let capacity = values.volumeAvailableCapacityForImportantUsage {
        print("Available capacity for important usage: \(capacity)")
    } else {
        print("Capacity is unavailable")
    }
} catch {
    print("Error retrieving capacity: \(error.localizedDescription)")
}

Answer 3

I have the same result on iPhone5 with iOS 6.1.4.

double freeSpaceMB = -1.;     
long long freeSpace =
            [[[[NSFileManager defaultManager]
            attributesOfFileSystemForPath:NSHomeDirectory()
                                    error:nil] objectForKey:NSFileSystemFreeSize] longLongValue];
        freeSpaceMB = (freeSpace * 1.)/ (1024 * 1024);   

X - Value from Settings (Usage)

I always get freeSpaceMB = X + 200.

I guess it is something reserve space in iOS. But it is just guessing.

Answer 4

Another question got posted yesterday that was closed as a duplicate of this one, and that one demonstrates another way you might have gotten this wrong.

What that questioner did was this:

uint64_t freeSpace = (uint64_t)[fileSystemAttributes objectForKey:NSFileSystemFreeSize];

NSLog(@"Free space in bytes: %lld.",freeSpace);

They treated the object itself (more precisely, the object's address in memory) as the number of free bytes. This is wrong; the object is an NSNumber object, which wraps such a number. The correct code would ask the object for its unsignedLongLongValue, which is of the correct type and therefore large enough to hold the correct value.