Cloud sync clients: OneDrive, Google Drive and Dropbox

A sync client turns an ordinary file operation into an upload: copying or moving a file into a watched folder is enough to send it to the cloud, with no browser and no visible transfer. This lesson covers where OneDrive, Google Drive for desktop and Dropbox keep account details, file databases and logs on Windows, why a file in a sync folder may have no content in the image, and how to combine local and provider evidence to answer "was this file uploaded, when, and from which account?". The client formats are mostly undocumented and change between versions, so treat every database and log layout below as typical of recent versions and confirm it on the evidence.

OneDrive

OneDrive is built into Windows 10 and 11 and runs as OneDrive.exe in each user's session, by default from %LOCALAPPDATA%\Microsoft\OneDrive\ (per-machine installations use Program Files). A personal Microsoft account syncs by default to C:\Users\<user>\OneDrive; a work or school account syncs to C:\Users\<user>\OneDrive - <Organization>, for example OneDrive - Contoso. SharePoint libraries synced by the same work account appear under a folder named after the organization.

Account configuration in NTUSER.DAT

Each signed-in account has a key under NTUSER.DAT\Software\Microsoft\OneDrive\Accounts\: Personal for a Microsoft account and Business1 (then Business2 and so on) for work or school accounts. The keys hold values such as UserEmail (the sign-in address) and UserFolder (the local sync root), and the personal key holds the account's cid, a 16-hex-digit identifier that also names files in the settings folder. Because the key is in the user's own hive, it ties a sync root and an email address to a Windows profile. Last-write times of the key show when the client last changed its configuration, not when files synced.

Settings folder and the sync database

%LOCALAPPDATA%\Microsoft\OneDrive\settings\ has one subfolder per account type, Personal and Business1. Inside are small text files, <cid>.ini (the synced libraries and their local paths) and global.ini (client settings), and the client's file database:

• SyncEngineDatabase.db in current versions. It is SQLite, so collect its -wal and -shm files too. Tables such as od_ClientFile_Records and od_ClientFolder_Records hold one row per file or folder known to the client, with the name, a resource ID, the parent folder's resource ID, the size, a content hash and timestamps. Rebuilding a full path means following parent IDs up to the root.
• <cid>.dat in older versions: an undocumented binary file with similar file and folder entries. It may still be present on systems that upgraded.

The hash depends on the account type and service: work accounts use Microsoft's QuickXorHash, a 160-bit value usually stored as 28 Base64 characters, and personal accounts have used SHA-1. QuickXorHash is not MD5 or SHA-256, so to match a file in the image against a database row you must compute the same algorithm over the file. Tools such as OneDriveExplorer rebuild the folder tree from these databases; DB Browser for SQLite lets you inspect the rows directly.

ODL logs

%LOCALAPPDATA%\Microsoft\OneDrive\logs\ holds subfolders such as Personal, Business1 and Common. The sync engine writes binary ODL logs (.odl, compressed .odlgz, and .odlsent; the set of extensions varies between versions) that record sync operations, including uploads, downloads, renames and deletions, with a timestamp per entry. File names and other strings in the logs are protected: older versions replaced them with tokens listed in ObfuscationStringMap.txt, and newer versions encrypt them with a key kept in a general.keystore file. Decoders such as Yogesh Khatri's OneDrive ODL parser need that file from the same installation; without it you see operations but not names. Collect the whole logs tree, and check which time zone the parser uses for its output.

Files On-Demand and Known Folder Move

With Files On-Demand, which current clients turn on by default, a file can be online-only: the name, size and timestamps exist locally, but the content stays in the cloud until opened. NTFS stores such a file as a reparse point with cloud attributes (for example FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS, often with FILE_ATTRIBUTE_OFFLINE), and its $DATA has no allocated clusters. A file that is "present" in OneDrive - Contoso may therefore have no content in the image; report it as a placeholder and request the content from the provider. Files the user marks "Always keep on this device" are pinned and fully local.

Known Folder Move redirects known folders such as Desktop, Documents and Pictures into the OneDrive folder. Check NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders (values Desktop, Personal for Documents, and My Pictures): if they point into OneDrive, every file saved to the desktop was a sync candidate.

The OneDrive recycle bin, version history and sharing links live in the cloud. They are provider data, not endpoint artifacts.

Google Drive for desktop

Google Drive for desktop (GoogleDriveFS.exe) keeps its data in %LOCALAPPDATA%\Google\DriveFS\. Each account has a subfolder named by a long numeric account ID, containing:

• metadata_sqlite_db (SQLite, no extension) with tables such as items and item_properties: names, parent relationships, size, modified time and a stable_id that links rows across tables.
• content_cache, a folder of cached file content in files without their original names or extensions. Identify them by signature and size, then match them to database rows.

Databases such as root_preference_sqlite.db in the DriveFS folder hold account and mount preferences. Logs are plain text: %LOCALAPPDATA%\Google\DriveFS\Logs\drive_fs.txt and rotated drive_fs_<n>.txt files, readable with any text editor or grep.

By default the client streams My Drive through a virtual drive, usually G:. That drive is not an NTFS volume, so files on it have no $MFT entries in the disk image; only cached content and the database describe them. In mirror mode files are also stored in a local folder and behave like ordinary NTFS files.

Dropbox

Dropbox stores its sync folder path in info.json, found in %LOCALAPPDATA%\Dropbox\ or %APPDATA%\Dropbox\, with a path value for each personal or business account. Client data sits in %LOCALAPPDATA%\Dropbox\instance1\ (more instances for more accounts). Files with the .dbx extension, such as config.dbx and aggregation.dbx, are encrypted SQLite databases whose key is protected by DPAPI (Windows Data Protection API), so decrypting them needs the user's DPAPI key material or a live session. Other files such as sync_history.db have been readable in some versions and encrypted in others. Test each file before relying on it: a plain SQLite file starts with the 16-byte string SQLite format 3 followed by a null byte at offset 0, and an encrypted one does not.

The hidden .dropbox.cache folder in the sync root keeps copies of recently deleted or changed files for a short period, typically a few days. It can hold content that no longer exists anywhere else on the disk.

Comparing the clients

Method: was file X uploaded, when, and from which account?

No single artifact answers the question. Build it from independent sources:

1. File system. Find the file in the sync folder. Its $SI creation time records when the file was created, which survives a move; a move or rename into the folder appears in $J as RENAME_OLD_NAME and RENAME_NEW_NAME records, and a copy appears as a new file created there (Lesson 1.4).
2. Client database. Find the row with the same name, parent folder and size. A database row means the client knew about the file; a matching hash ties it to the content.
3. Client log. Find the upload entry and its completion time.
4. SRUM. Check bytes sent by OneDrive.exe, GoogleDriveFS.exe or Dropbox.exe in the interval that contains the upload (Lesson 2.8).
5. Account. Tie the sync root to the account through the registry, info.json or the DriveFS account folder.
6. Provider. Where available, the Microsoft 365 unified audit log (operations such as FileUploaded and FileSyncUploadedFull) or the Google Workspace Drive audit log confirms the upload, the account and the client IP address.

Triage collections must include the settings and logs folders above. A collection that only takes registry hives and event logs cannot answer this question.

Worked example

User ana copies q3-files.7z from the USB drive E:\ (the archive created in Lesson 3.4) into C:\Users\ana\OneDrive - Contoso\Shared\. The evidence:

Checks. The upload completed 14:01:41 − 14:01:03 = 38 seconds after the file entered the folder. 64,108,233 bytes × 8 / 38 s = 13.5 Mbit/s, a plausible upload rate. 64,108,233 / 1,048,576 = 61.1 MiB. SRUM bytes sent exceed the file size by 64,812,544 − 64,108,233 = 704,311 bytes (about 1.1%), which fits protocol overhead and other sync traffic in the same interval; SRUM cannot show that the bytes were this file. If the file is still local, compute its QuickXorHash and compare it with the database value.

Statement. "At 2026-03-14T14:01:03Z the file q3-files.7z (64,108,233 bytes) was copied from the USB drive E:\ into C:\Users\ana\OneDrive - Contoso\Shared\, the sync folder of the work account ana@contoso.com configured in the profile of user ana. The OneDrive client database lists the file in that folder with the same size, and the client log records its upload as complete at 2026-03-14T14:01:41Z. SRUM records 64,812,544 bytes sent by OneDrive.exe in the interval 13:31:09Z–14:31:09Z, consistent with the upload. The Microsoft 365 unified audit log for the Contoso tenant should be requested to confirm the upload server-side." The statement does not say who was at the keyboard, and it does not claim the file was shared with anyone.

Exam focus: Expect a Part B task asking which file was uploaded through OneDrive and when, answered from the parsed ODL logs and SyncEngineDatabase.db, with the account taken from Accounts\Business1 or Accounts\Personal. Know the settings and logs paths, that ODL strings need ObfuscationStringMap.txt or general.keystore, and that an online-only placeholder has no content in the image. Be ready to separate the time a file arrived in the sync folder ($J) from its creation time ($SI) and its upload time (log).

Key points

• OneDrive accounts are in NTUSER.DAT\Software\Microsoft\OneDrive\Accounts\Personal and Business1, with values such as UserEmail and UserFolder.
• settings\<account>\SyncEngineDatabase.db (SQLite in current versions, <cid>.dat in older ones) lists files with parent IDs, sizes and hashes; logs\<account>\*.odl records uploads, downloads and deletions.
• ODL strings are obfuscated or encrypted; decoding needs ObfuscationStringMap.txt or general.keystore from the same system, so collect the whole logs tree.
• Files On-Demand placeholders are reparse points with cloud attributes and no local content; Google Drive's streamed G: drive has no MFT entries at all.
• Dropbox .dbx databases are DPAPI-protected and encrypted; info.json gives the sync path and .dropbox.cache may hold recently deleted files.
• Prove an upload with the file system, client database, client log and SRUM together, and request provider audit logs for server-side confirmation.