Graph API search/query not recording file size over 4gb (over 2^32 bytes) correctly

Question

Graph API search/query not recording file size over 4gb (over 2^32 bytes) correctly

Albert 0

Hi,

I'm having this issue where I'm trying to search for files using the graph api's search/query with something like this:

POST 
{
  "requests": [{
    "entityTypes": ["driveItem"],
    "query": { "queryString": "Size>=4294967296" },
    "from": 0,
    "size": 25,
    "fields": ["name", "size", "fileTotalSize"],
    "sortProperties": [{ "name": "Size", "isDescending": true }]
  }]
}

But the files I see in my tenant that are over 4gb are not returning back. The fileTotalSize is properly returning back the file's sizes, though some of them returns additional size due to versions on the files, but the item's size is not correctly returning for files over 4gb.

But when I lower my threshold to 1GB and re-run the query, I see that my 5gb and 6gb files are being returned, but it looks like the size that its returning is its actual size minus 2^32gb. (ie. 5gb file is returning as 1gb, 6gb file is returning as 2gb)

Can you help me understand why this is happening? is there a bug with the search/query index that's not properly storing/retrieving the size value?

0 comments

2 answers

Your answer

Answer 1

The arithmetic you observed is a classic unsigned 32-bit overflow: values above 4,294,967,296 bytes (2^32, which is exactly 4 GiB) wrap around by that constant, so a 5 GiB file is reported as roughly 1 GiB and a 6 GiB file as roughly 2 GiB. This strongly suggests that the Microsoft Search index is storing the Size field as a 32-bit integer rather than a 64-bit integer, so the indexed value truncates whenever a file exceeds 4 GiB and the search filter Size>=4294967296 never matches those rows. To confirm, compare the search result for an affected file against a direct GET request to /drives/{driveId}/items/{itemId}/?$select=size; the driveItem endpoint returns the full 64-bit size while the search index returns the wrapped value, which isolates the bug to the Search indexing or response path. As a workaround, do not filter on the indexed Size property for large files; instead retrieve candidates and validate the actual size using the driveItem endpoint, and consider reporting the 4 GiB boundary to Microsoft Support with client-request-id and request-id headers so the Search team can fix the managed property.

Answer 2

Compare each affected Search hit with a direct GET driveItem request; if the direct response contains the correct 64-bit size while /search/query returns the value modulo 2^32, report it as a Microsoft Search service defect and do not use the indexed Size property for filtering files above 4 GiB.

Why the values wrap

Your examples follow an exact unsigned 32-bit wraparound:

5 GiB = 5,368,709,120 bytes → reported as 1,073,741,824 bytes
6 GiB = 6,442,450,944 bytes → reported as 2,147,483,648 bytes
Difference: 4,294,967,296 bytes, exactly 2^32

That is strong evidence that the Search representation of Size is being truncated or converted through a 32-bit numeric value. Microsoft’s documented Search limitations do not list a 4-GiB file-size boundary ^1^, and SharePoint’s published search limits likewise do not document such a limit for the Size managed property ^2^.

This establishes a likely overflow defect, but not whether it occurs while indexing, evaluating KQL, serializing the Search response, or parsing it in your client.

Isolate Search from driveItem metadata

Take the driveId and item ID from an affected Search hit, then request the item directly:

GET https://graph.microsoft.com/v1.0/drives/{drive-id}/items/{item-id}?$select=id,name,size
Authorization: Bearer {token}
client-request-id: {new-guid}

The direct endpoint retrieves the item’s metadata and returns a driveItem; it requires at least delegated Files.Read, or Files.Read.All for application access ^3^. size is a documented property of that resource ^4^.

Compare the raw JSON, before SDK or application deserialization:

Run your existing /search/query request and save the raw response.
Run the direct request above for the same item.
Compare:
- Search size
- Search fileTotalSize
- Direct driveItem.size
Repeat with files just below and above 4,294,967,296 bytes.

Interpret the result as follows:

Direct size correct; Search size wrapped: the problem is in the Microsoft Search/index response path.
Both raw responses correct; application value wrapped: change the client model to a 64-bit integer, such as C# long, Java long, or JavaScript number/BigInt as appropriate.
Both raw responses wrapped: provide both requests to Microsoft Support because the issue is not isolated to Search.

Microsoft Search officially supports returning OneDrive and SharePoint files as driveItem results and supports KQL property restrictions only where the managed property is valid and queryable ^5^. Therefore, changing >= syntax or sorting direction is unlikely to correct an indexed value that has already wrapped.

Workaround

There is no documented query expression that reconstructs the original value after a 2^32 truncation. Until Microsoft fixes or confirms the behavior:

Do not rely on Size>=4294967296 or Search sorting by Size.
Retrieve candidate items and validate each one with GET /drives/{drive-id}/items/{item-id}?$select=id,name,size.
If every file must be evaluated, enumerate the drive hierarchy and follow pagination, then filter on the direct driveItem.size values. Search alone cannot reliably identify all affected files because a file between 4 and 5 GiB can wrap to a value below 1 GiB.

Report the defect

Send a unique client-request-id with each reproduction and retain the response request-id and Date headers. Microsoft specifically requests these values for diagnosing Graph failures ^6^.

Include:

Tenant cloud/region, without posting tenant identifiers publicly.
Exact UTC timestamp.
Raw Search and direct-driveItem requests and responses.
client-request-id, response request-id, and Date.
Expected and actual byte values.
A minimal set of test files immediately below and above 2^32.
Confirmation that the same behavior occurs outside your SDK, such as with Graph Explorer or another raw HTTP client.

References