End to End Testing of OneDrive Client for Linux
September 9, 2026 · View on GitHub
| Test Case Results |
|---|
 |
 |
 |
 |
 |
 |
This document describes the end-to-end (E2E) automated testing framework used to validate the behaviour of the OneDrive Client for Linux.
The test suite runs inside GitHub Actions and performs real synchronisation operations against Microsoft OneDrive using dedicated test accounts.
The objective of the test framework is to ensure that all client functionality continues to operate correctly across future changes to the application.
Personal and Business Account Testing
Personal and Business end-to-end testing executes the full automated test suite against the default drive associated with the authenticated account, without explicitly specifying a drive_id in the client configuration. In this mode, the Microsoft Graph API implicitly resolves the user’s primary drive (personal OneDrive or business OneDrive root) and all drive enumeration, metadata retrieval, path traversal, upload, download, delete, and synchronisation operations are performed within that default context. As a result, the same comprehensive set of test cases validates client behaviour, configuration handling, and synchronisation correctness using the standard account-bound drive, ensuring expected operation without any explicit drive targeting or override.
Note: Personal Shared Folder testing and Business Shared Folder testing are performed separately because OneDrive shared folder shortcuts introduce different path resolution, metadata, drive discovery, shortcut anchoring, and filtering behaviour from standard account-root synchronisation.
SharePoint Account Testing
SharePoint end-to-end testing uses the same complete automated test suite as Personal OneDrive and OneDrive for Business, but changes the target drive by supplying a drive_id value in the client configuration. This means the harness is not merely repeating the same account-type tests against the same default drive context; it is explicitly forcing the client to enumerate, access, and operate against a different Microsoft Graph drive object, resulting in different drive discovery, metadata enumeration, path traversal, upload, download, delete, and synchronisation API activity. By injecting drive_id into the test configuration, every existing test case is executed against a SharePoint document library context rather than a personal or business default OneDrive root, ensuring that the full suite validates client behaviour, configuration handling, and synchronisation correctness when operating against SharePoint-backed storage.
Test Case Details
| Test Case | Description | Account Coverage | Test Details |
|---|---|---|---|
| 0001 | Basic Resync | - Personal - Business - SharePoint | - validate that the E2E framework can invoke the client - validate that the configured environment is sufficient to run a basic sync - provide a simple baseline smoke test before more advanced E2E scenarios |
| 0002 | 'sync_list' Validation | - Personal - Business - SharePoint | This validates sync_list as a policy-conformance test. The test is considered successful when all observed sync operations involving the fixture tree match the active sync_list rules. This test covers exclusions, inclusions, wildcard and globbing for paths and files. Specific 'sync_list' test coverage is as follows: - Scenario SL-0001: root directory include with trailing slash - Scenario SL-0002: root include without trailing slash - Scenario SL-0003: non-root include by name - Scenario SL-0004: include tree with nested exclusion - Scenario SL-0005: included tree with hidden directory excluded - Scenario SL-0006: file-specific include inside named directory - Scenario SL-0007: rooted include of Programming tree - Scenario SL-0008: exclude Android recursive build output and include Programming - Scenario SL-0009: exclude Android recursive .cxx content and include Programming - Scenario SL-0010: exclude Web recursive build output and include Programming - Scenario SL-0011: exclude .gradle anywhere and include Programming - Scenario SL-0012: exclude build/kotlin anywhere and include Programming - Scenario SL-0013: exclude .venv and venv anywhere and include Programming - Scenario SL-0014: exclude common cache and vendor directories and include Programming - Scenario SL-0015: complex style Programming ruleset - Scenario SL-0016: massive mixed rule set across Programming Documents and Work - Scenario SL-0017: stress test kitchen sink rule set with broad include and targeted file include - Scenario SL-0018: exact trailing slash configuration with cleanup validation - Scenario SL-0019: no trailing slash workaround with cleanup validation - Scenario SL-0020: focused trailing slash Projects regression for sibling path survival - Scenario SL-0021: focused no trailing slash Projects regression for sibling path survival - Scenario SL-0022: exact root-file include - Scenario SL-0023: sync_root_files = true with rooted 'Projects' include - Scenario SL-0024: cleanup regression with 'sync_root_files = true' - Scenario SL-0025: prefix-collision safety for 'Projects/Code' - Scenario SL-0026: mixed rooted subtree include plus exact root-file include - Scenario SL-0027: wildcard directory include across similarly named Project Code folders - Scenario SL-0028: globbing directory include for src directories across nested project depths - Scenario SL-0029: wildcard directory include with deeper wildcard exclusion - Scenario SL-0030: globbing directory include with recursive globbing exclusion - Scenario SL-0031: normal directory include with deeper wildcard exclusion must not exclude ancestor - Scenario SL-0032: normal directory include with deeper globbing exclusion must not exclude ancestor - Scenario SL-0033: generic wildcard include with per-matched-container child exclusion - Scenario SL-0034: generic globbing include traverses multiple seeded trees without premature pruning - Scenario SL-0035: generic exact file include with sibling wildcard exclusion - Scenario SL-0036: generic path with spaces using wildcard and globbing include - Scenario SL-0037: generic cleanup_local_files with included root and excluded child subtree - Scenario SL-0038: generic cleanup_local_files with wildcard include and excluded sibling container children - Scenario SL-0039: generic sync_root_files override retains logical root files without entering unrelated fixture subtrees |
| 0003 | Dry-run safety validation | - Personal - Business - SharePoint | This test validates that running the client with --dry-run performs a full synchronisation analysis without making any changes locally or remotely. Files and directories are created in the test environment, the client is executed with --dry-run, and the test verifies that no filesystem or remote changes occur. |
| 0004 | Single-directory sync scope validation | - Personal - Business - SharePoint | This test validates that the --single-directory option restricts synchronisation to the specified directory subtree. Only the nominated directory should be synchronised, while other directories outside the scope must remain untouched. |
| 0005 | Force-sync override validation | - Personal - Business - SharePoint | This test validates that the --force-sync option overrides blocking conditions that would normally prevent synchronisation of a single-directory scope. The test confirms that forced synchronisation proceeds even when skip rules would otherwise block the operation. |
| 0006 | Download-only sync validation | - Personal - Business - SharePoint | This test validates the behaviour of the --download-only option. Remote content is seeded in OneDrive and the client is executed in download-only mode. The test verifies that the remote data is correctly downloaded locally without performing any upload operations. |
| 0007 | Download-only cleanup validation | - Personal - Business - SharePoint | This test validates the behaviour of --cleanup-local-files when used with --download-only. Local files that no longer exist remotely should be removed during synchronisation while valid remote content is preserved. |
| 0008 | Upload-only sync validation | - Personal - Business - SharePoint | This test validates that --upload-only mode correctly uploads local files and directories to OneDrive. The test ensures that no download operations occur and that remote content reflects the locally created files. |
| 0009 | Upload-only remote preservation validation | - Personal - Business - SharePoint | This test validates the behaviour of the --no-remote-delete option when used with --upload-only mode. The test confirms that remote files are not deleted even when they do not exist locally. |
| 0010 | Upload-only source removal validation | - Personal - Business - SharePoint | This test validates the --remove-source-files option used with --upload-only mode. After files are successfully uploaded to OneDrive, the local source files should be automatically removed. |
| 0011 | Skip-file pattern validation | - Personal - Business - SharePoint | This test validates that skip_file configuration patterns correctly exclude matching files from synchronisation. Files matching the configured patterns should not be uploaded or downloaded. |
| 0012 | Skip-directory rule validation | - Personal - Business - SharePoint | This test validates skip_dir as a client-side filtering rule across both local filesystem processing and remote OneDrive processing. It validates unanchored directory-name matching, skip_dir_strict_match full-path behaviour, explicit sync-root anchored paths, single- and multi-segment path rules, wildcard matching, case-insensitive matching, multiple configured patterns, and equivalent filtering behaviour across upload and download directions.Specific coverage is as follows: - Scenario SD-0001: unanchored skip_dir = "Cache" with skip_dir_strict_match = false validates local-to-remote filtering, excluding matching Cache directories at both shallow and nested depths while retaining unrelated content- Scenario SD-0002: repeats the unanchored non-strict Cache rule against remotely seeded content and validates remote-to-local filtering at both shallow and nested depths- Scenario SD-0003: skip_dir_strict_match = true with an explicit multi-segment path validates local-to-remote filtering where only the configured full path is excluded and a same-named sibling directory outside that path remains synchronised- Scenario SD-0004: repeats the strict explicit multi-segment path rule against remotely seeded content and validates equivalent remote-to-local behaviour - Scenario SD-0005: a leading-slash single-segment rule such as skip_dir = "/DirectoryName" with strict matching disabled validates sync-root anchoring during full remote-to-local processing: [sync_dir]/DirectoryName is excluded while the same directory name below another parent remains synchronised- Scenario SD-0006: repeats the leading-slash single-segment sync-root anchored rule with skip_dir_strict_match = true, confirming that the leading slash remains an explicit sync-root anchor and does not match the same directory name at deeper levels- Scenario SD-0007: a leading-slash multi-segment path containing spaces and a trailing slash validates non-strict remote-to-local filtering, excluding only the intended sync-root-relative path while retaining a deeper path with the same trailing suffix - Scenario SD-0008: repeats the rooted multi-segment path-with-spaces and trailing-slash case with strict matching enabled - Scenario SD-0009: mixed local-to-remote rules validate repeated skip_dir entries, pipe-separated patterns, * and ? wildcards, case-insensitive directory matching, and an explicit rooted wildcard rule; the rooted wildcard must not exclude the same matching name when it appears below an additional parent- Scenario SD-0010: repeats the mixed wildcard, case-insensitive, repeated-entry and rooted-wildcard rule set against remotely seeded content to validate equivalent remote-to-local filtering |
| 0013 | Dotfile exclusion validation | - Personal - Business - SharePoint | This test validates the 'skip_dotfiles' option. Files and directories beginning with a dot (.) should be excluded from synchronisation when this option is enabled. |
| 0014 | File size exclusion validation | - Personal - Business - SharePoint | This test validates the 'skip_size' option. Files exceeding the configured size threshold should be excluded from synchronisation. |
| 0015 | Symlink exclusion and dangling symlink validation | - Personal - Business - SharePoint | This test validates symbolic link handling and the skip_symlinks configuration option. It confirms that symbolic links present in the local filesystem are not synchronised when skipping is enabled, and that dangling symbolic links are handled safely without client crash when symlink processing is enabled.Specific coverage is as follows: - Scenario SYM-0001: skip_symlinks = true with a valid symbolic link validates that the regular source file is synchronised while the symbolic link itself is excluded- Scenario SYM-0002: skip_symlinks = false with a dangling symbolic link validates that the invalid path is actually exercised without the client terminating with an uncaught filesystem exception and that the broken symbolic link is not uploaded as remote content. An unrelated sibling control file is retained as diagnostic evidence but is not a pass/fail assertion because local scan ordering may encounter the intentionally invalid path first |
| 0016 | .nosync directory exclusion validation | - Personal - Business - SharePoint | This test validates the 'check_nosync' feature. Directories containing a .nosync marker file should be excluded from synchronisation. |
| 0017 | .nosync mount protection validation | - Personal - Business - SharePoint | This test validates the 'check_nomount' safeguard. When a .nosync marker exists in the mount point of the synchronisation directory, the client should abort synchronisation to prevent unintended operations. |
| 0018 | Recycle bin integration validation | - Personal - Business - SharePoint | This test validates integration with the FreeDesktop-compliant recycle bin. When files are deleted remotely, the client should move them into the configured recycle bin instead of permanently deleting them when the feature is enabled. The test also validates Recycle Bin filename collision handling and associated .trashinfo metadata naming.Specific coverage is as follows: - a remotely deleted file is moved into an empty Recycle Bin using its original filename - an existing filename collision generates the .2 suffix while preserving the original file extension- successive collisions generate .3 and .4 suffixes- collision filenames do not contain the malformed double-dot extension separator, for example file.2..data- the corresponding .trashinfo filename exactly matches the generated recycled filename- files without an extension are collision-renamed without introducing a trailing dot |
| 0019 | Logging and runtime configuration validation | - Personal - Business - SharePoint | This test validates that the client correctly writes logs to a configured 'log_dir' and that --display-running-config outputs the effective runtime configuration. |
| 0020 | Monitor mode real-time sync validation | - Personal - Business - SharePoint | This test validates that when the client runs in --monitor mode, filesystem changes made while the process is running are automatically detected and synchronised without manually re-running the client. This validates inotify-based filesystem event handling under real-time event propagation conditions. |
| 0021 | Resumable transfer recovery validation | - Personal - Business - SharePoint | This test validates resumable upload and download session behaviour, including source-identity validation before upload resumption and recovery when an active upload session becomes invalid and must be replaced. Large file transfers are deliberately slowed and interrupted only after measurable transfer progress has been observed, then recovered using the same client state. The test confirms that resumable state is actually created before interruption, that incomplete transfers do not masquerade as completed transfers, that subsequent client execution can recover safely, and that replacement upload-session state remains authoritative for all subsequent fragments. Specific coverage is as follows: - Scenario RT-0001: resumable upload recovery creates a large local file, interrupts the active upload after the configured progress threshold is reached, verifies that resumable upload-session state remains on disk, reruns the client using the same state, validates that upload-session recovery is exercised, and independently verifies that the remote file completes successfully - Scenario RT-0002: resumable download recovery seeds a large remote file, interrupts the active download after the configured progress threshold is reached, verifies that resumable download state is retained, reruns the same client state to resume the transfer, and validates the completed local file and independently verified remote fixture - Scenario RT-0003: resumable upload recovery with a source path changed into a dangling symbolic link first creates and interrupts a real upload session, then replaces the original source pathname with a dangling symlink before retrying. Recovery must exercise the stale upload session without crashing, remove the now-invalid session_upload* state, and must not upload the dangling symbolic-link source as remote content. A sibling control file is retained as diagnostic evidence but is not a pass/fail requirement because processing order may encounter the intentionally invalid path first- Scenario RT-0004: modified multi-fragment XLSX upload-session replacement validation programmatically generates a valid XLSX workbook at runtime using deterministic high-entropy random worksheet data, avoiding any embedded large binary or text fixture while ensuring the resulting workbook exceeds two 10 MiB upload fragments. The workbook is initially uploaded and the resulting local canonical copy is validated before modification so that any SharePoint Office-document enrichment performed after the first upload is retained. The harness then modifies a real worksheet revision marker in place without artificially inflating the file size and performs a second synchronisation of the existing tracked XLSX. Personal and Business account runs validate the complete real modified-file multi-fragment session-upload workflow and independently download and validate the final workbook revision. SharePoint testing additionally requires the service to exercise the 404 itemNotFound / The upload session was not found recovery path observed for modified Office documents. When that occurs, the client must create and adopt a replacement upload session, restart from the replacement session's advertised offset, and use the replacement session GUID consistently for every subsequent fragment rather than returning to the superseded session URL. The scenario fails if the replacement session is not adopted, if subsequent fragment PUTs revert to the original session GUID, if nameAlreadyExists is returned, if a safeBackup is created, if stale session_upload* state remains after successful completion, or if the modified upload does not complete. A fresh independent download-only verification client then validates that the remotely stored XLSX is structurally valid and contains the expected modified worksheet revision.- Scenario RT-0005: interrupted upload source-identity validation creates a genuine 100 MiB multi-fragment upload using deterministic revision A, interrupts it only after remote progress has produced a non-zero nextExpectedRanges offset and persisted session_upload.* state, then replaces the local source with a different revision B of exactly the same byte size and a distinct local modification timestamp. The recovery run must reject the old resumable session because its persisted sourceFileSize / full-precision sourceFileMtime identity no longer matches the local source, perform best-effort cancellation of the stale Microsoft upload session, remove the stale local session state, and allow normal reconciliation to begin a fresh upload from zero. An independent download-only verification client then confirms that the final remote object exactly matches revision B by byte size and SHA-256 hash and does not match revision A. |
| 0022 | Local-first conflict resolution validation | - Personal - Business - SharePoint | This test validates the 'local_first' configuration option. When a file conflict occurs between local and remote versions, the client should treat the local file as the authoritative source and update the remote version accordingly. |
| 0023 | Bypass data preservation validation | - Personal - Business - SharePoint | This test validates the behaviour of the 'bypass_data_preservation' option. When enabled, the client should suppress the creation of safe-backup files during conflict resolution and allow remote content to overwrite local changes. |
| 0024 | Big delete safeguard validation | - Personal - Business - SharePoint | This test validates the 'classify_as_big_delete' protection mechanism. When a large number of items are deleted locally, the client should halt synchronisation and emit a warning. The deletion should only proceed after the user explicitly acknowledges the action using --force. This also validates consistent safeguard behaviour across account types where API timing or enumeration differences may occur. |
| 0025 | Invalid character filename validation | - Personal - Business - SharePoint | This test validates that invalid filename characters are blocked while valid sibling files still synchronise |
| 0026 | Reserved device name validation | - Personal - Business - SharePoint | This test validates that reserved Windows device names are blocked while valid lookalike names still synchronise |
| 0027 | Whitespace and trailing dot validation | - Personal - Business - SharePoint | This test validates that trailing whitespace and trailing dot names are blocked while valid sibling files still synchronise |
| 0028 | Control character and non-UTF8 filename validation | - Personal - Business - SharePoint | This test validates that control characters and non-UTF8 filenames are safely skipped without client crash while valid sibling files still synchronise |
| 0029 | Upload-only + Local First sync validation | - Personal - Business - SharePoint | This test validates that --local-first --upload-only uploads local content without rewriting local file timestamps from Microsoft API response data |
| 0030 | Local rename propagation validation | - Personal - Business - SharePoint | This test validates that renaming a local file is correctly propagated to remote state |
| 0031 | Local directory rename propagation validation | - Personal - Business - SharePoint | This test validates that renaming a local directory tree is correctly propagated to remote state |
| 0032 | Remote file rename reconciliation | - Personal - Business - SharePoint | This test validates that a stale local client correctly reconciles a remote-side file rename without leaving stale local leftovers |
| 0033 | remote directory rename reconciliation | - Personal - Business - SharePoint | This test validates that a second client with existing local and database state correctly reconciles a remote directory rename propagated by another synchronising client |
| 0034 | Local move between directories validation | - Personal - Business - SharePoint | This test validates that moving a local file from one directory to another is correctly propagated to remote state |
| 0035 | Remote move between directories reconciliation | - Personal - Business - SharePoint | This test validates that a stale local client correctly reconciles a remote-side file move between directories without leaving stale local file leftovers |
| 0036 | Overwrite / replace existing file content validation | - Personal - Business - SharePoint | This test validates that replacing the contents of an existing local file with the same name correctly updates remote content without leaving stale content or metadata confusion |
| 0037 | mtime-only local change handling | - Personal - Business - SharePoint | This test validates mtime-only local file changes without changing file content across direct upload and session-upload paths. Each scenario seeds a file, independently verifies the initial remote state, changes only the local modification time while confirming the content hash is unchanged, performs reconciliation, and then independently verifies the final remote content and timestamp behaviour. Specific coverage is as follows: - Scenario MT-0001: 1 MiB file using default direct-upload behaviour - Scenario MT-0002: 5 MiB file using automatic session-upload behaviour for files larger than 4 MiB - Scenario MT-0003: 1 MiB file with force_session_upload = true- Scenario MT-0004: 5 MiB file with force_session_upload = trueAcross all four scenarios the file content and size must remain unchanged, the mtime-only path must be explicitly detected, and the final remote timestamp behaviour must match the transfer path being exercised |
| 0038 | Delete and recreate with same name validation | - Personal - Business - SharePoint | This test validates that deleting a file, syncing that deletion, then recreating a different file with the same name correctly results in the final remote and local state without stale item-id or state database issues |
| 0039 | Empty directory handling | - Personal - Business - SharePoint | This test validates that creation, sync, verification, and cleanup behaviour for empty directories, including nested empty directories, to ensure directory-only state is created and removed correctly |
| 0040 | Nested tree rename and delete stress validation | - Personal - Business - SharePoint | This test validates that a combined nested-tree mutation scenario involving multiple renames, one deletion, and one new file creation before a single sync, ensuring the final remote and fresh-download state is correct with no stale paths left behind |
| 0041 | Monitor mode local create upload | - Personal - Business - SharePoint | This test validates starting --monitor, create a local file, and validate it uploads without restarting the client |
| 0042 | Monitor mode local modify upload | - Personal - Business - SharePoint | This test validates modifying an existing local file under --monitor and validate the update propagates |
| 0043 | Monitor mode local delete propagation | - Personal - Business - SharePoint | This test validates deleting a local file under --monitor and validate the remote delete occurs as expected |
| 0044 | Monitor mode local rename propagation | - Personal - Business - SharePoint | This test validates renaming a local file while --monitor is active and validates correct behaviour |
| 0045 | Monitor mode local directory create propagation | - Personal - Business - SharePoint | This test validates creating a new local directory and child file under --monitor and validate the remote state |
| 0046 | Monitor mode local directory rename propagation | - Personal - Business - SharePoint | This test validates renaming a populated local directory while --monitor is active and validate the final remote state |
| 0047 | Monitor mode local directory delete propagation | - Personal - Business - SharePoint | This test validates deleting a populated local directory tree under --monitor and validate the remote delete |
| 0048 | Monitor mode burst local file creates | - Personal - Business - SharePoint | This test rapidly create multiple local files under --monitor and validate they all upload correctly |
| 0049 | Monitor mode mixed burst operations | - Personal - Business - SharePoint | This test performs create, modify, delete, and rename operations in one burst under --monitor and validate the final state |
| 0050 | Monitor mode nested file create inside new directory | - Personal - Business - SharePoint | This test creates a nested directory tree and deep file under --monitor and validate the remote state |
| 0051 | Monitor mode mtime-only local change handling | - Personal - Business - SharePoint | This test touches an existing local file under --monitor without changing content and validate that no new upload occurs |
| 0052 | Monitor mode large file create session upload | - Personal - Business - SharePoint | This test creates a large file under --monitor and validate session upload behaviour and remote integrity |
| 0053 | Monitor mode rename then modify | - Personal - Business - SharePoint | This test renames a file and then modify the renamed file under --monitor and validate the final remote state |
| 0054 | Monitor mode atomic-save and completed-file hand-off workflows | - Personal - Business - SharePoint | This test validates two temporary-file finalisation workflows while the client is running under --monitor, ensuring that completed local file changes are handled immediately through the filesystem event path rather than being deferred until the normal monitor_interval reconciliation.Specific coverage is as follows: - Scenario AS-0001: existing atomic-save editor replacement writes updated content to a temporary .swp pathname and uses an atomic os.replace() operation to replace an already-synchronised target, validating the existing rename/move-based monitor workflow and final remote content- Scenario AS-0002: completed-file hand-off writes and closes a non-skipped temporary .staging file, creates the final pathname as a hard link to the completed file, then removes the temporary pathname, deliberately generating the Linux IN_CREATE -> IN_CLOSE_WRITE -> IN_CREATE -> IN_DELETE pattern without IN_MOVED_FROM / IN_MOVED_TO; the final pathname must be uploaded immediately before the 300-second monitor interval can recover it, the temporary pathname must not be uploaded, and fresh remote verification must contain only the expected final content |
| 0055 | Upload-only remove-source-folders | - Personal - Business - SharePoint | This test validates that remove_source_folders removes empty local directory structure after upload-only succeeds |
| 0056 | Monitor mode create then delete quickly | - Personal - Business - SharePoint | This test creates and delete a local file quickly under --monitor and validate stability and final remote state |
| 0057 | Recycle bin delete behaviour validation | - Personal - Business - SharePoint | This test validates Recycle Bin handling for both online-origin and local-origin deletes, including regression coverage for a failed local Recycle Bin move after an authoritative online deletion. Specific coverage is as follows: - Scenario S01: online delete with use_recycle_bin=false validates that remotely deleted content is removed locally without creating configured Recycle Bin payload or .trashinfo metadata- Scenario S02: online delete with use_recycle_bin=true validates that remotely deleted content is moved into the configured local Recycle Bin and that matching FreeDesktop .trashinfo metadata is created- Scenario S03: local delete with use_recycle_bin=false validates that a locally removed populated directory is propagated to OneDrive as a remote deletion without creating configured Recycle Bin data- Scenario S04: local delete with use_recycle_bin=true validates that local-origin deletion is still propagated online and is not incorrectly treated as a remote-origin Recycle Bin operation simply because Recycle Bin support is enabled- Scenario S05: online delete with failed Recycle Bin move validates safe handling when a remotely deleted local item cannot be moved into the configured Recycle Bin. The test uses the established multi-client E2E operating model: tracked state is seeded on a primary client, the complete client configuration/database state and local tree are cloned, and the cloned endpoint runs under --monitor --upload-only to delete a populated directory locally and produce a genuine remote deletion while the primary client remains stale. The primary client is configured with a Recycle Bin under /dev/shm, and the harness confirms that sync_dir and recycle_bin_path have different filesystem device IDs so the local rename() operation fails with the cross-filesystem EXDEV class of error. The scenario verifies that the failed move is reported, the local directory and child file remain present, no Recycle Bin payload is created, and no misleading .trashinfo metadata is written. The same retained primary-client state then performs a normal bidirectional follow-up sync, after which a fresh independent verification client confirms that the surviving local object is not re-uploaded to OneDrive. |
| 0058 | Monitor download-only cleanup cadence | - Personal - Business - SharePoint | This test validates monitor_authoritative_sync behaviour when the client is running in --monitor --download-only mode with --cleanup-local-files. It confirms that authoritative cleanup is controlled by the configured monitor policy and distinguishes authoritative cleanup from normal Microsoft Graph /delta processing.Specific coverage is as follows: - Scenario MSIGNAL: monitor_authoritative_sync = "monitor_and_signal" validates that an authoritative cleanup pass is performed and DB-known stale local content is removed- Scenario MINTERVAL: monitor_authoritative_sync = "monitor_interval" validates that authoritative cleanup occurs during monitor interval processing- Scenario MFULLSCAN: monitor_authoritative_sync = "monitor_fullscan_frequency" validates that the first monitor pass uses native /delta processing and defers authoritative cleanup until the configured full-scan cadence- Scenario NOCLEANUP: validates that without --cleanup-local-files, local-only stale content is retainedThe test uses debug-level monitor output to validate the active policy path, because remote tombstone handling can remove files independently of authoritative cleanup and may vary across Personal, Business, and SharePoint drive contexts. |
| 0059 | WebSocket remote upload notification | - Personal - Business - SharePoint | This test validates near-real-time Microsoft Graph WebSocket notification handling by running one client in --monitor mode with an isolated --confdir and sync directory, then using a second isolated client running --sync --upload-only to upload a new file. The monitor client must receive the WebSocket signal, process the resulting /delta, and download the remotely uploaded file without relying on the normal monitor_interval cadence. |
| 0060 | Monitor mode local move reconciliation without delete/re-upload | - Personal - Business - SharePoint | This test validates that moving already synchronised local files and populated directory trees while running under --monitor --verbose is correctly propagated as remote move operations rather than delete and re-upload behaviour. The test performs local inotify-triggered move operations while the client is actively monitoring the filesystem, validates that remote state is updated to the new path location, and confirms through debug log analysis that stale descendant delete operations and unnecessary re-upload activity do not occur during reconciliation. |
| 0061 | Remote move into skip_dir reconciliation | - Personal - Business - SharePoint | This test validates that when a second synchronising endpoint running in --monitor mode moves previously synchronised files from a normal synced path into a destination excluded via skip_dir, the original Linux client correctly reconciles the remote move using its existing local database state. The test confirms that stale local source files are removed from the original synced location, skipped destination content is not downloaded locally, unrelated sibling files remain preserved, and the moved files remain correctly online in the skipped destination path. |
| 0062 | Transfer Metrics validation | - Personal - Business - SharePoint | This test validates that upload and download transfer metric reporting is generated correctly when running with --verbose --verbose. The test confirms that transfer statistics are emitted for both upload and download operations, validates reported file size accuracy, verifies the presence of separate network transfer and end-to-end processing duration fields, and ensures transfer speed reporting is correctly formatted using Mbps units. |
| 0063 | Local parent path rename during active download | - Personal - Business - SharePoint | This test validates client behaviour when a local parent directory is renamed while a file download is actively in progress during a normal synchronisation operation using local_first = true. The test confirms that local filesystem races are correctly detected and reported, that download failures are handled safely without client instability or database corruption, and that local filesystem failures are not incorrectly reported as Microsoft Graph API HTTP status code errors. |
| 0064 | Local authoritative remote mirror validation | - Personal - Business - SharePoint | This test validates the mirror_local_state configuration option when used with local_first = true. The test confirms that during a full --resync --resync-auth operation, remote-only files and directories that no longer exist locally are removed from Microsoft OneDrive rather than being downloaded, ensuring the remote state becomes an exact mirror of the local filesystem. |
| 0065 | sync_list remote directory move reconciliation | - Personal - Business - SharePoint | This test validates reconciliation of remote directory moves and renames when the affected directory is already known to the local client and is within the active sync_list scope. It confirms that sync_list filtering does not prematurely replace the existing database parent/path state before normal move reconciliation occurs, allowing the client to recognise and apply the remote operation as a directory move or rename rather than treating the destination as a new directory and the retained source tree as locally deleted content.The test verifies that populated directory trees are moved locally from their existing source path to the new remote path, that the destination directory is not incorrectly pre-created for an already-known item, that child items remain associated with the moved directory, and that reconciliation does not produce false local-delete detection, unintended remote deletion, stale source trees, unnecessary uploads, or delete/recreate/re-upload feedback loops. Specific coverage is as follows: - Scenario S01: bidirectional parent directory move validates that an already-synchronised populated directory moved remotely to a different parent is reconciled locally as a move while preserving its existing tracked state and child content - Scenario S02: bidirectional same-parent directory rename validates that an already-synchronised populated directory renamed remotely within the same parent is reconciled locally as a rename without destination pre-creation, stale source content, or unnecessary upload activity - Scenario S03: download-only parent directory move validates that a remote move of an already-known populated directory to a different parent is correctly applied by a download-only client without generating any upload or remote-delete activity - Scenario S04: monitor reconciliation validates the same remote directory move behaviour while the receiving client is running in --monitor mode, confirming that monitor-triggered reconciliation preserves the existing database/local path state until the normal move handling path performs the local directory move- Scenario S05: download-only mixed post-move modify/delete lifecycle validates continued reconciliation after a remote directory move by applying subsequent modifications and deletions within the moved tree, confirming that changed children remain associated with the new path, deleted children are removed correctly, retained content remains intact, and the final online, database, and local filesystem state converges without stale entries or false feedback operations |
| 0066 | safeBackup transactional replacement validation | - Personal - Business - SharePoint | This test validates the normal tracked-file safeBackup replacement transaction when both the local file and the online file have changed from a previously synchronised baseline and the online version is newer. The test establishes a common baseline, modifies the tracked local file, independently uploads a newer online replacement from another client, and then performs normal reconciliation on the stale local client. The test confirms that successful conflict resolution preserves both sides of the conflict correctly: the canonical local pathname remains present and contains the authoritative online replacement, exactly one safeBackup is created containing the exact displaced local bytes, no staged .partial files remain after the completed replacement, and a fresh download-only verification client confirms that the canonical online file contains the expected authoritative replacement content. |
| 0067 | safeBackup interrupted replacement validation | - Personal - Business - SharePoint | This test validates the safeBackup transaction boundary when an active replacement download is interrupted before it can commit. A 32 MiB tracked baseline file is changed locally, a newer 80 MiB replacement is uploaded remotely, and the receiving client is configured with a 5 MiB/s rate_limit, application logging, and force_xfer_abort = "true". The harness watches real transfer progress and sends SIGINT only after at least 15% of the replacement has been downloaded, while also confirming that the transfer did not complete before interruption.The test verifies that interruption cannot remove or alter the pre-existing canonical file: the canonical pathname must still exist and its QuickXor hash must still match the locally modified pre-replacement bytes. If any safeBackup exists at the interrupted point, it must contain those same preserved canonical bytes. The same client state is then reused for a normal recovery run, which must successfully commit the authoritative remote replacement to the canonical pathname, retain exactly one safeBackup containing the displaced local bytes, and leave no .partial files behind. |
| 0068 | safeBackup upload-only conflict validation | - Personal - Business - SharePoint | This test validates safeBackup handling for a tracked-file conflict while the stale local client is running in --upload-only mode. After establishing a synchronised baseline, the local tracked file is modified while another client independently uploads a newer version of the same canonical file online.The test confirms that upload-only conflict handling does not download the newer online version over the local canonical file and does not remove the canonical pathname. The locally modified canonical file must remain present with its original local bytes, exactly one local safeBackup must preserve those same bytes, the newer online canonical file must remain unchanged, and a fresh verification client must confirm that the preserved local conflict was uploaded to OneDrive under its safeBackup filename. |
| 0069 | safeBackup remote move destination collision validation | - Personal - Business - SharePoint | This test validates safeBackup behaviour when a remote file move must be reconciled into a local destination pathname that is already occupied by unsynchronised local content. The test establishes synchronised source and destination-directory state on two clients, creates an unsynchronised local file at the future destination on the receiving client, then uses the second client to move the tracked remote source file into that occupied destination and propagate the move online. The receiving client reconciles the move in download-only mode. The test confirms that the stale source pathname is removed, the remotely moved file takes the expected canonical destination pathname, the displaced local destination content is preserved exactly once as a safeBackup with matching bytes, and a fresh verification client confirms the final remote move state without a stale source object. |
| 0070 | safeBackup new-file upload collision validation | - Personal - Business - SharePoint | This test validates the separate no-database/new-local-file collision path under --upload-only. The local client begins with an older untracked local file while another client seeds a newer online file at the exact same pathname, so the local client has no established database identity for the colliding file when upload-only reconciliation begins.The test confirms that the older local canonical file remains present and unchanged, exactly one local safeBackup preserves its bytes, and upload-only processing does not replace the newer online canonical file. A fresh download-only verification client must also confirm that the online canonical file still contains the newer remote content and that the preserved local bytes were uploaded remotely under a safeBackup filename. |
| 0071 | safeBackup metadata-only identity validation | - Personal - Business - SharePoint | This test validates that a metadata-only difference is not misclassified as a content conflict requiring safeBackup preservation. A remote file is seeded, then a separate local client is given a file with identical content but a deliberately divergent local modification time and no established local database identity for that file. During resync reconciliation, the client must recognise content identity, retain the canonical file contents unchanged, create no safeBackup, and leave no .partial file. The deliberately divergent local modification time must be corrected, and a fresh download-only verification client is used to confirm both that the online content remained unchanged and that the reconciled local modification time matches the authoritative metadata represented by a fresh download. |
| 0072 | safeBackup preservation failure aborts replacement | - Personal - Business - SharePoint | This test deterministically validates the hard-failure behaviour when safeBackup preservation cannot be created. After establishing a tracked baseline, the local canonical file is modified and a newer authoritative replacement is uploaded remotely. The harness then pre-creates all 1000 safeBackup filenames in the exact safeBackup-0001 through safeBackup-1000 allocation range as empty non-matching files. The local test configuration excludes *-safeBackup-* and .partial files from synchronisation so these fault-injection artifacts remain local and cannot affect the remote fixture.The reconciliation run must exercise the real safeBackup allocation-exhaustion path, including the expected allocation-failure and replacement-refusal diagnostics. Most importantly, failure to preserve the local file must abort replacement: the canonical pathname must remain present with exactly the same pre-replacement local bytes and hash, no staged replacement .partial file may remain, and a fresh verification client must confirm that the authoritative online file was not changed by the failed local preservation attempt. |
| 0073 | safeBackup existing preservation reuse validation | - Personal - Business - SharePoint | This test validates retry/reconciliation behaviour when an exact same-device safeBackup already preserves the current canonical local version. After establishing a tracked baseline, the local file is modified and the harness creates the expected safeBackup-0001 using a metadata-preserving copy so that its content and metadata match the current canonical file. Another client then uploads a newer online replacement.Reconciliation must recognise and reuse the existing valid preservation instead of creating safeBackup-0002 or another duplicate. The canonical pathname must converge to the newer remote content, exactly one safeBackup must remain and it must be the original matching preservation containing the displaced local bytes, and verbose output must confirm that the existing-preservation reuse path was actually exercised rather than merely arriving at the same filesystem state through another path. |
| 0074 | safeBackup clean resync no-conflict validation | - Personal - Business - SharePoint | This test explicitly validates that --resync itself does not create a safeBackup when local and online state are already fully in sync. The test seeds a remote file, uses a persistent local client state to download it and establish a tracked in-sync baseline, records the canonical content/hash/mtime, and then performs a second --sync --resync --resync-auth using the same local sync directory without making any local or online change.The repeated resync must rebuild state without treating the unchanged canonical file as conflicting data: the canonical pathname must remain present with exactly the same content and hash, no safeBackup may be created, and no .partial file may remain. A fresh download-only verification client then confirms that the online file also remained unchanged. This is distinct from TC0071, which starts without an established local DB identity and intentionally introduces a metadata-only difference. |
| 0075 | safeBackup remote-delete local-modification validation | - Personal - Business - SharePoint | This test validates the one intentional safeBackup workflow where the canonical pathname is expected to disappear. A remote file is seeded and downloaded by two independent clients so both have tracked baseline state. The receiving client then independently modifies its local file while the second client deletes the tracked file and propagates that deletion to OneDrive. When the receiving client reconciles the authoritative online deletion, it must recognise that the local bytes no longer match the last in-sync database baseline and preserve those locally modified bytes by renaming the file to exactly one safeBackup. The original canonical pathname must then be absent locally, no .partial file may remain, and a fresh verification client must confirm that the canonical online file remains deleted and that the preserved safeBackup was uploaded with the expected content. This explicitly regression-tests the sole destructive safeBackup path that is intentionally retained by the implementation. |
| 0076 | safeBackup resync content-conflict validation | - Personal - Business - SharePoint | This test validates the positive safeBackup side of a --resync/no-database conflict. A remote file is seeded, while a fresh local client with no usable database identity is given a different same-path local file. The client then performs --sync --resync --resync-auth.Because the local and authoritative online bytes genuinely differ and there is no previous DB baseline that can prove the local file is unchanged, reconciliation must preserve the pre-resync local bytes as exactly one safeBackup and place the authoritative online content at the canonical pathname. No .partial file may remain, and a fresh verification client confirms the online canonical content and the uploaded safeBackup. Together with TC0071 and TC0074, this proves that --resync does not itself cause safeBackup creation: identical content produces no safeBackup, while genuinely different same-path content is preserved. |
| 0077 | Timestamp authority safety gating validation | - Personal - Business - SharePoint | This test validates system-time authority safety gating across --monitor and --sync operation, ensuring that unsafe local clock drift prevents timestamp-sensitive synchronisation until system time is corrected and revalidated, unless the user has explicitly disabled time validation.Specific coverage is as follows: - Scenario TA-0001: --monitor startup with unsafe clock drift validates that synchronisation remains suspended while the process stays running, and that normal monitor startup and synchronisation automatically resume after system time is corrected and successfully revalidated- Scenario TA-0002: active --monitor clock-drift recovery validates that an already-running monitor suspends synchronisation when the local clock becomes unsafe, does not propagate queued local changes while blocked, and resumes processing those changes after system time is corrected and revalidated- Scenario TA-0003: --sync startup with unsafe clock drift validates that synchronisation does not begin and the client exits with failure after confirmed blocking clock drift is detected- Scenario TA-0004: unsafe clock drift with --disable-time-check validates that the explicit time-validation override bypasses the clock safety gate, permits normal synchronisation to proceed despite otherwise blocking clock drift, and confirms through independent remote verification that local content is successfully propagated to OneDrive |
| 0078 | Monitor mode rename to an invalid name | - Personal - Business - SharePoint | This test validates that renaming an already-synced item to a name that cannot be represented on Microsoft OneDrive preserves the existing online copy, rather than removing it. TC0025 validates that items created with an invalid name are skipped, and TC0044 and TC0046 validate renames between valid names. Neither covers the intersection: an item that is already online being renamed locally into a name the Microsoft naming rules reject. Such an item has not left the sync scope - it is still inside sync_dir, it simply cannot be named online - so the online copy is the only synchronised copy of data that still exists locally.Specific coverage is as follows: - a complete tree is seeded online and verified by manifest and content before any rename occurs, so the post-rename comparison is made against a known-good baseline - a synced file is renamed under --monitor into a name containing characters rejected by the Microsoft naming rules, validating that no remote deletion is attempted and that the move is not misclassified as a move out of sync scope- a synced directory is renamed the same way, validating that the tracked subtree is detached as a unit and that no child is left behind to be reinterpreted later - a subsequent reconciliation pass, followed by a convergence pass, validates that the preserved online copies are not removed one cycle later once stale local database tracking would otherwise have made the old paths look locally deleted - an independent verification client confirms that the complete remote manifest and the content of every file are unchanged from the seeded baseline |
| 0079 | Display sync status bidirectional read-only validation | - Personal - Business - SharePoint | This test validates the redesigned --display-sync-status command as a read-only, bidirectional reconciliation assessment rather than a remote-only change query.Specific coverage is as follows: - Scenario DS-0001 establishes a tracked clean --single-directory baseline and validates Overall status: IN SYNC, clean remote and local direction summaries, and the read-only contract by proving that the live items.sqlite3, local filesystem content/mtime state and temporary no-sync database cleanup remain unchanged by the query- Scenario DS-0001B runs the same clean local state from an isolated client-state copy configured with force_children_scan = true without --single-directory, validating the conservative full-scope Overall status: INDETERMINATE result where the normal /delta status path is unavailable- Scenario DS-0002 creates local-only divergence consisting of a same-size content modification, a timestamp-only modification, a new 90-byte file, a new empty directory and a locally deleted tracked file; it validates the corresponding local counters, exact sub-1-KiB transfer-size display, NOT IN SYNC, and confirms that a skip_file-excluded local file is not counted- the local changes are reconciled and a second scoped status query must return to IN SYNC, proving that the command reflects current reconciliation state rather than retaining stale findings- Scenario DS-0003 uses the established two-client monitor E2E operating model: an independent mutator runs --monitor --upload-only --single-directory while the evaluated client remains completely passive. The mutator applies a real DriveItem rename, tracked remote deletion, file modification, zero-byte file creation, 2048-byte file creation, empty-directory creation and an evaluator-filtered file creation, waiting for the corresponding monitor/remote action after each mutation. The evaluated client then runs --display-sync-status --single-directory, validating authoritative read-only /children current-state comparison, deletion-by-absence, preserved move identity, zero-byte-file detection, 2.09 KB (2144 bytes) transfer reporting and filtering- Scenario DS-0004 adds a new local 77-byte file to the still-stale evaluated client while the DS-0003 remote changes remain unapplied; both directions must be reported simultaneously as NOT IN SYNC, and the complete scoped remote metrics must remain visible on the repeated read-only query- prerequisite failures terminate dependent phases immediately so a single setup/monitor failure cannot be misreported as a large set of secondary status-metric failures - every completed status invocation independently verifies that the live database hash and local tree state are unchanged and that temporary items-dryrun.sqlite3 artifacts are removed after the command exits |
OneDrive Personal Shared Folder Testing
Personal Shared Folder end-to-end testing validates client behaviour when synchronising content accessed via OneDrive shared folder shortcuts.
Unlike standard directory structures, shared folders are represented through shortcut-style access to content that may be backed by different OneDrive drive items. This introduces unique behaviour in path resolution, metadata handling, shortcut anchoring, and sync_list evaluation.
These tests ensure that:
- shared folder shortcuts are correctly discovered and traversed
- preserved shared folder topology is pulled down without creating ghost folders
- linked shared folder content is synchronised without corrupting local path structure
sync_listrules correctly apply across shared folder shortcut boundaries- renamed, nested, and path-with-spaces shared folders remain anchored correctly
- wildcard, globbing, inclusion, exclusion, and cleanup scenarios behave correctly for shared folder paths
- safe test mutations do not unintentionally modify preserved shared folder fixture content
Personal Shared Folder Test Case Details
| Test Case | Description | Account Coverage | Test Details |
|---|---|---|---|
| 0001 | Personal shared folders clean sync pull down | - Personal | This test validates that --sync --verbose pulls down the preserved Personal Account shared folder topology without creating ghost folders. It confirms that shared folder shortcuts are discovered, traversed, and materialised locally using the expected path structure. |
| 0002 | Personal shared folders clean monitor pull down | - Personal | This test validates that --monitor --verbose pulls down the preserved Personal Account shared folder topology without creating ghost folders. It confirms that monitor mode can initialise shared folder content correctly and remain stable while filesystem monitoring is active. |
| 0003 | Personal shared folders sync_list validation | - Personal | This validates sync_list include and exclude behaviour across the preserved Personal Account shared folder topology without creating ghost folders.The test is considered successful when all observed sync operations involving the shared folder fixture topology match the active sync_list rules, including shortcut path anchoring and resolved shared folder paths.Specific Personal Shared Folder sync_list coverage is as follows:- Scenario SL-0001: rooted include of one shared folder tree with trailing slash - Scenario SL-0002: rooted include of one shared folder tree without trailing slash - Scenario SL-0003: rooted include of deep shared folder path - Scenario SL-0004: include shared folder tree with nested exclusion - Scenario SL-0005: file-specific include inside a shared folder - Scenario SL-0006: multiple file-specific includes within one shared folder - Scenario SL-0007: include nested tree shared folder and exclude sibling shared folder trees - Scenario SL-0008: mixed includes across minimal renamed and deep shared folders - Scenario SL-0009: include shared folder path containing spaces - Scenario SL-0010: multiple explicit shared-folder shortcut includes only - Scenario SL-0011: safe tracked mutation inside an existing shared-folder directory - Scenario SL-0012: explicit Family pictures shared-folder includes only - Scenario SL-0013: wildcard shared-folder directory include across WIDE_SET shortcuts - Scenario SL-0014: globbing include for a file below a shared-folder directory tree - Scenario SL-0015: normal shared-folder include with deeper wildcard exclusion - Scenario SL-0016: normal shared-folder include with deeper globbing exclusion - Scenario SL-0017: wildcard shared-folder include with wildcard exclusion of one matched shortcut's children - Scenario SL-0018: wildcard shared-folder include with globbing exclusion of one matched file - Scenario SL-0019: shared-folder shortcut name collision with different per-shortcut exclusions - Scenario SL-0020: shared-folder exact file include with sibling wildcard exclusion - Scenario SL-0021: shared-folder path with spaces using wildcard and globbing include - Scenario SL-0022: renamed shared folder include remains anchored without ghost sibling creation - Scenario SL-0023: shared-folder globbing include across TREE shortcut variants - Scenario SL-0024: cleanup_local_files removes local-only stale file under included shared-folder parent |
OneDrive Business Shared Folder Testing
Business Shared Folder end-to-end testing validates client behaviour when synchronising content accessed via OneDrive for Business shared folder shortcuts.
Unlike standard Business account-root synchronisation, shared folders are represented through shortcut-style access to content that may be backed by different OneDrive drive identifiers and remote document library contexts. This introduces unique behaviour in drive discovery, path resolution, metadata handling, shortcut anchoring, and sync_list evaluation.
These tests ensure that:
- Business shared folder shortcuts are correctly discovered and traversed
- preserved Business shared folder topology is pulled down without creating ghost folders
- linked shared folder content is synchronised without corrupting local path structure
sync_listrules correctly apply across Business shared folder shortcut boundaries- wildcard, globbing, inclusion, exclusion, and cleanup scenarios behave correctly for Business shared folder paths
- deep path traversal behaves correctly across different shared folder drive contexts
- similarly named shared folder trees remain correctly isolated during wildcard and globbing evaluation
- safe test mutations do not unintentionally modify preserved Business shared folder fixture content
Business Shared Folder Test Case Details
| Test Case | Description | Account Coverage | Test Details |
|---|---|---|---|
| 0001 | Business shared folders clean sync pull down | - Business | This test validates that --sync --verbose pulls down the preserved Business Account shared folder topology without creating ghost folders. It confirms that Business shared folder shortcuts are discovered, traversed, and materialised locally using the expected path structure. |
| 0002 | Business shared folders clean monitor pull down | - Business | This test validates that --monitor --verbose pulls down the preserved Business Account shared folder topology without creating ghost folders. It confirms that monitor mode can initialise Business shared folder content correctly and remain stable while filesystem monitoring is active. |
| 0003 | Business shared folders sync_list validation | - Business | This validates sync_list include and exclude behaviour across the preserved Business Account shared folder topology without creating ghost folders.The test is considered successful when all observed sync operations involving the shared folder fixture topology match the active sync_list rules, including shortcut path anchoring, resolved shared folder paths, SharePoint-backed shared folders, user-owned shared folders, renamed shared-folder shortcuts, root-level shared-folder shortcuts, and different Business shared-folder drive contexts.Specific Business Shared Folder sync_list coverage is as follows:- Scenario SL-0001: rooted include of one Business shared folder tree with trailing slash - Scenario SL-0002: rooted include of one Business shared folder tree without trailing slash - Scenario SL-0003: rooted include of deep Business shared folder path - Scenario SL-0004: include Business shared folder tree with nested exclusion - Scenario SL-0005: file-specific include inside a Business shared folder - Scenario SL-0006: multiple file-specific includes within one Business shared folder - Scenario SL-0007: include nested Business shared folder tree and exclude sibling shared folder trees - Scenario SL-0008: mixed includes across minimal renamed and deep Business shared folders - Scenario SL-0009: include Business shared folder path containing spaces - Scenario SL-0010: multiple explicit Business shared-folder shortcut includes only - Scenario SL-0011: safe tracked mutation inside an existing Business shared-folder directory - Scenario SL-0012: wildcard Business shared-folder directory include across WIDE_SET trees - Scenario SL-0013: globbing include for a file below a Business shared-folder directory tree - Scenario SL-0014: normal Business shared-folder include with deeper wildcard exclusion - Scenario SL-0015: normal Business shared-folder include with deeper globbing exclusion - Scenario SL-0016: wildcard Business shared-folder include with wildcard exclusion of one matched shortcut's children - Scenario SL-0017: wildcard Business shared-folder include with globbing exclusion of one matched file - Scenario SL-0018: Business shared-folder exact file include with sibling wildcard exclusion - Scenario SL-0019: Business shared-folder path with spaces using wildcard and globbing include - Scenario SL-0020: renamed Business shared folder include remains anchored without ghost sibling creation - Scenario SL-0021: Business shared-folder globbing include across TREE shortcut variants - Scenario SL-0022: cleanup_local_files removes local-only stale file under included Business shared-folder parent - Scenario SL-0023: deep Business shared-folder globbing include with retained sibling empty directory structure - Scenario SL-0024: explicit Business shared-folder subtree include across different shared-folder drive contexts - Scenario SL-0025: exact file include across multiple Business shared-folder roots - Scenario SL-0026: explicit subtree include across multiple Business shared-folder roots - Scenario SL-0027: mixed Business shared-folder include and exclusion behaviour across different shortcut-backed drive identifiers - Scenario SL-0028: SharePoint-backed shared-folder root include from non-default drive context - Scenario SL-0029: SharePoint-backed deep shared-folder include retains correct ancestor path anchoring - Scenario SL-0030: user-owned shared-folder root include outside default Data container - Scenario SL-0031: renamed shared-folder shortcut remains isolated during wildcard traversal - Scenario SL-0032: apostrophe-containing shared-folder path include and exclusion handling - Scenario SL-0033: root-level and Data-level shared-folder wildcard traversal across mixed SharePoint and user-owned sources - Scenario SL-0034: mixed SharePoint-backed and user-owned shared-folder exact file include validation across different remote drive identifiers |
| 0004 | Business shared files clean sync pull down | - Business | This test validates that --sync --verbose --sync-shared-files correctly enumerates and materialises OneDrive Business Shared Files into the Files Shared With Me local topology, preserving per-user grouping, file versus folder classification, and mixed shared-owner handling using the Microsoft Graph Search API replacement for the deprecated sharedWithMe endpoint. |
| 0005 | SharePoint library enumeration while monitor is running | - Business | This test validates that --get-sharepoint-drive-id '*' is treated as a no-sync operation and can be executed successfully using the exact same configuration directory, state database, and authentication context while another client instance is actively running in --monitor mode. The test confirms that SharePoint library discovery and enumeration continue to function correctly without triggering active-client detection, database-lock failures, or other concurrency restrictions intended only for synchronisation operations. |
Contributing Additional Test Cases
While this end-to-end test suite provides broad and comprehensive coverage of the OneDrive Client for Linux, it is not exhaustive. Real-world usage continues to surface new edge cases, behaviours, and scenarios that may not yet be represented here.
If you identify a gap in coverage, encounter a scenario that is not currently validated, or believe an existing test case could be improved, contributions are strongly encouraged. Please feel free to raise a discussion outlining the scenario, or ideally develop and submit a new test case via a pull request following the existing test framework structure.
Community contributions play a critical role in strengthening the reliability and robustness of the client, and all well-defined additions are welcomed.