| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
Add project sponsorship visibility to initial graphical authentication (#3867) ## Summary This PR adds restrained GitHub Sponsors visibility to the OneDrive Client for Linux while deliberately avoiding recurring or intrusive sponsorship messaging. Following a successful **initial graphical authentication**, the browser completion page now includes an optional invitation to help sustain the project through GitHub Sponsors. The sponsorship message is not displayed during `--reauth`, authentication failures, application startup, monitor startup, normal synchronisation activity, terminal output or desktop notifications. ## Changes - Enhances the graphical authentication completion page with a clearer responsive layout and application identity. - Displays the sponsorship section only after successful initial graphical authentication. - Does not display sponsorship content during explicit `--reauth`. - Adds an attributable GitHub Sponsors link using GitHub Sponsors campaign metadata. - Adds passive sponsorship information to the project README and graphical-authentication documentation. - Adds browser response protections including `Referrer-Policy: no-referrer`, `Cache-Control: no-store`, a restrictive Content Security Policy and `X-Content-Type-Options: nosniff`. - Does not add application telemetry, click tracking or any new configuration option. ## Sponsorship Behaviour The graphical authentication page displays: > Help sustain OneDrive Client for Linux OneDrive Client for Linux is free, open-source software that is independently developed and maintained. If it is useful to you or your organisation, you can help sustain ongoing development, testing and maintenance through GitHub Sponsors. The user must explicitly select **Sponsor on GitHub** before any connection to GitHub is made. GitHub Sponsors campaign metadata is used only to attribute completed sponsorships to the relevant project surface. ## Privacy The application does not report whether the sponsorship message was displayed or selected. No application telemetry or analytics have been added. The local OAuth completion response explicitly prevents the Microsoft OAuth callback URL from being supplied as a browser referrer when following the external sponsorship link. | 24 天前 | |
Update architecture documentation (#3870) * Update architecture documentation | 21 天前 | |
Implement FR #3787: Use different browser with --reauth and friends (#3848) ## Overview This pull request implements the feature request raised in #3787 to allow a user to explicitly select which browser is used for interactive Microsoft authentication. The current GUI authentication path launches the Microsoft authorisation URL using `xdg-open`. This means the desktop environment's configured default browser is normally selected. In environments where a user intentionally uses a different browser for Microsoft 365 authentication, setting the standard `BROWSER` environment variable does not reliably override that desktop preference because `xdg-open` may successfully select the desktop-configured browser before consulting `BROWSER`. For example, a user may use Firefox as their normal desktop browser while using Microsoft Edge exclusively for Microsoft 365 authentication and SSO. This change allows that user to run: ```bash BROWSER=/usr/bin/microsoft-edge-stable onedrive --reauth ``` and have the Microsoft authentication URL opened directly using Microsoft Edge. ## Changes The browser launch logic in `src/localAuth.d` has been updated so that: 1. If the `BROWSER` environment variable is set, the client first attempts to launch the configured executable directly with the Microsoft authorisation URL. 2. If the configured browser cannot be launched, the failure is written to the debug log and the client falls back to the existing `xdg-open` behaviour. 3. If `BROWSER` is not set, behaviour remains unchanged and `xdg-open` is used as before. 4. If browser launch ultimately fails, the existing authentication fallback behaviour remains unchanged. Both an explicit executable path: ```bash BROWSER=/usr/bin/microsoft-edge-stable onedrive --reauth ``` and an executable available through `PATH`: ```bash BROWSER=microsoft-edge-stable onedrive --reauth ``` are supported. ## Design Considerations This change deliberately does not attempt to automatically detect Microsoft Edge or introduce a Microsoft Edge-specific configuration option. `BROWSER` is treated as a user-selected browser executable, making the implementation browser-neutral and allowing the same mechanism to be used with Firefox, Chromium, Chrome, Edge or another browser. The value is passed directly to `spawnProcess()` as an executable rather than being executed through a shell. This keeps the authentication path deterministic and avoids introducing shell command parsing into OAuth browser launching. The existing behaviour remains the fallback path, so an invalid or stale `BROWSER` value does not prevent authentication from proceeding through the normal desktop browser. ## Behaviour With no override configured: ```bash unset BROWSER onedrive --reauth ``` the existing desktop/default-browser behaviour is retained. With an explicit browser configured: ```bash BROWSER=/usr/bin/microsoft-edge-stable onedrive --reauth ``` the selected browser is used for Microsoft authentication. If the configured browser does not exist or cannot be started: ```bash BROWSER=/does/not/exist onedrive --reauth ``` the client falls back to `xdg-open`. ## Scope This is intentionally a laser-focused change. There are no changes to: * OAuth request or response handling * local loopback authentication * GUI session detection * authentication callback processing * device authentication * headless or SSH authentication behaviour * application configuration options * Microsoft Edge detection * the existing manual authentication fallback Only the browser-selection step of the existing GUI authentication workflow is changed. | 1 个月前 | |
Add notify_monitor_start option to silence monitor-start notification (#3779) Addresses discussion #3109 Running in `--monitor` mode sends a GUI notification on every startup confirming that filesystem monitoring has begun. There was previously no way to silence just this notification short of disabling all notifications via `disable_notifications`. * Add `notify_monitor_start` config option (default `true`, preserving existing behaviour) that gates only the monitor-start GUI notification * Document the option in `config`, `docs/application-config-options.md` and `docs/usage.md` To disable just this notification, add this to your cofig: ``` notify_monitor_start = "false" ``` Checked to compile with LDC v1.20.1 (Debian) and LDC 1.42.0 (Fedora). | 1 个月前 | |
OneDrive Client for Linux v2.5.0 (#2805) OneDrive Client for Linux v2.5.0 --------- Signed-off-by: Thomas Staudinger <Staudi.Kaos@gmail.com> Co-authored-by: JC-comp <147694781+JC-comp@users.noreply.github.com> Co-authored-by: Dimitri Papadopoulos Orfanos <3234522+DimitriPapadopoulos@users.noreply.github.com> Co-authored-by: Pierrick Caillon <megamisan@users.noreply.github.com> Co-authored-by: Pierrick Caillon <pierrick.caillon@megami.fr> Co-authored-by: Thomas Staudinger <Staudi.Kaos@gmail.com> Co-authored-by: Yuan Liu <Lyncredible@users.noreply.github.com> | 2 年前 | |
Update minimum compiler version details (#3330) * Update minimum compiler version details * Update RHEL RPM documentation * Update spelling words | 1 年前 | |
Fix spelling problems as identified by GitHub Action check-spelling (#2946) * Fix spelling problems as identified by GitHub Action check-spelling | 1 年前 | |
Update architecture documentation (#3870) * Update architecture documentation | 21 天前 | |
Update Smoke Test (#3696) * Update Smoke Test and add documentation | 5 个月前 | |
Correct Docker documentation (#3605) * Correct Docker documentation as to distribution versions being used for the Docker images. This should have been updated with the December 2025 update | 8 个月前 | |
Fix Bug #3868: Fix false safeBackup on timestamp-preserving file replacements (#3869) Fix modified-file reconciliation when a local file is replaced with different content while preserving an older modification timestamp. This can occur through normal workflows such as: * `cp -p` * `rsync -t` * restoring files from backup * file managers that preserve source timestamps Previously, if the replacement content differed but its local modification timestamp was older than the online timestamp, the client could incorrectly conclude that the online file was newer. This caused the local replacement to be treated as a conflict even when the online object had not changed since the client's last synchronised state. The resulting behaviour was: ```text local content replaced with older preserved mtime | v classified as "online is newer" | v local replacement moved to safeBackup | v safeBackup uploaded as a new file | v existing online version downloaded back ``` This PR corrects that decision while retaining the existing data-preservation behaviour for genuine online changes. ## Root Cause `performModifiedFileUpload()` already retrieves fresh metadata for the online DriveItem before deciding how to process a modified local file. The existing conflict logic, however, primarily used: ```text localModifiedTime < onlineModifiedTime ``` to determine that the online version should take precedence. That assumption is not sufficient. A local file can contain new content while legitimately retaining an older timestamp. Importantly, the client also has another piece of information available at this point: the current online eTag. Where the freshly retrieved online eTag is unchanged from the eTag stored in the local database, the online object has not changed relative to the client's synchronised baseline. An older local timestamp alone therefore must not cause the local replacement to be classified as an online conflict. ## Change The modified-file upload decision now determines whether the current online DriveItem can be proven unchanged from the database baseline. The database baseline is trusted only when: * the current online object corresponds to the same DriveItem identity represented by the database entry; * the online item ID matches the expected target item; * both the current online eTag and database eTag are present and non-empty; * the current online eTag matches the database eTag; and * the client is not operating under `--resync`. When these conditions are satisfied: ```text different local content + older local timestamp + unchanged online eTag = local modification ``` The existing modified-file upload path is allowed to proceed. Where the online eTag has changed, is unavailable, cannot be safely associated with the same DriveItem identity, or the client is running under `--resync`, the existing conservative conflict handling remains unchanged. This intentionally keeps the fix narrowly focused on cases where the client can positively establish that the online object has not changed. ## `remoteItem` Handling Shared/remote items require additional care because the top-level database item and the actual target DriveItem can represent different identities. This PR does not attempt to redesign that behaviour. Where the current online object cannot be safely correlated with the database eTag baseline, the existing data-preservation path remains in effect. ## E2E Test Coverage The timestamp and replacement E2E coverage has been expanded to exercise actual Microsoft Office XLSX files rather than relying solely on synthetic text payloads. This is intentional because XLSX files can exercise additional Microsoft Graph and SharePoint behaviour, including SharePoint enrichment of uploaded Office documents. The existing XLSX implementation previously contained within TC0021 has been centralised into the E2E framework and TC0021 now consumes that common implementation. The shared XLSX helper supports: * creation of valid OOXML XLSX files; * validation of generated/downloaded workbooks; * mutation of existing workbooks while preserving other ZIP package members; and * generation of files on both sides of the simple/session upload boundary. This allows subsequent mutations to operate on the actual workbook returned by Microsoft, including any service-side package changes. ### TC0021 Existing resumable-transfer XLSX testing now uses the common XLSX framework implementation. The existing large-file/session-upload behaviour remains unchanged. ### TC0029 `--local-first --upload-only` timestamp-preservation testing now uses a real XLSX document. ### TC0036 Overwrite/replace coverage has been expanded substantially. #### OR-0001 — newer local replacement A synchronised XLSX is replaced with different XLSX content having a newer local timestamp. Expected result: * normal modified-file upload; * replacement becomes the canonical online content. #### OR-0002 — older timestamp, simple upload A synchronised XLSX is replaced using a timestamp-preserving copy operation with: * different content; * an older local modification timestamp; and * no independent online change. Expected result: * online eTag still matches the database baseline; * replacement is processed as a modified file; * no erroneous safeBackup is created; * canonical online content becomes the local replacement. This directly covers the reported failure condition. #### OR-0003 — older timestamp, session upload The same scenario as OR-0002 is performed using an XLSX larger than the simple-upload threshold. Expected result: * session upload is used; * modified upload succeeds; * no erroneous safeBackup is created. This confirms that the reconciliation fix operates correctly before upload-method selection. #### OR-0004 — genuine online conflict A separate mutator client is created using the established E2E multi-client model: ```text clone tracked configuration/database/local state | v mutator runs --monitor --upload-only | v mutator changes XLSX online | v remote modification independently verified | v stale client receives different local replacement with older preserved timestamp ``` Expected result: * current online eTag differs from the stale client's database baseline; * existing conflict handling remains active; * the local replacement is preserved through safeBackup; * the independently changed online version remains authoritative. This is the safety control demonstrating that the fix does not weaken protection against genuine online changes. ### TC0037 mtime-only local-change handling now uses XLSX files across: * simple upload-sized files; * automatic session-upload-sized files; * forced-session small files; and * forced-session large files. The downloaded Microsoft-returned workbook is used as the settled content baseline before timestamp-only mutations are performed. ### TC0051 Monitor-mode mtime-only testing now uses XLSX content and confirms that a timestamp-only local filesystem event does not result in an unnecessary upload or remote content change. ## Scope This PR does not change the general timestamp authority policy introduced by earlier timestamp work. It does not change: * Microsoft timestamp application after successful uploads; * simple versus session upload selection; * `--local-first` conflict policy; * `--resync` semantics; * genuine online-change conflict preservation; or * shared/remote item identity handling beyond refusing to trust an ambiguous eTag baseline. The change is deliberately limited to preventing an older preserved local timestamp from being treated as proof of an online conflict when the current online DriveItem can be positively demonstrated to be unchanged from the client's database baseline. | 20 天前 | |
Add support for OpenBSD (#3765) Add OpenBSD as a supported platform, including build-system integration, runtime portability fixes, improved crash diagnostics, and long-running monitor-mode validation. Build and platform support: * Detect the `egdc` compiler supplied with OpenBSD 7.9 and handle its GCC-style version output. * Harden compiler-version comparison when version components are absent. * Add the required `libexecinfo` linkage for OpenBSD GDC builds while preserving DMD compatibility. * Document supported OpenBSD releases, required packages, compiler availability, and build instructions. * Document that the OpenBSD 7.8 package repository does not provide a supported D compiler configuration. Runtime and diagnostic improvements: * Add OpenBSD-specific fatal signal handling using `SA_SIGINFO`. * Report the fault address, trap information, interrupted register context, and a native stack trace for segmentation faults. * Re-raise fatal signals after diagnostic output so normal core-dump handling is preserved. * Make database row data independently owned before extracting fields and parse stored timestamps safely before constructing database items. * Add coarse, time-gated garbage collection for long-running monitor processes, running no more than once every 24 hours after sync processing has completed. Microsoft Graph response hardening: * Validate Graph collection responses before accessing or iterating their `value` arrays. * Validate required item, parent-reference, shared-folder, search, upload, directory-creation, and WebSocket subscription fields before accessing them. * Harden path construction and remote item processing against missing or unexpectedly typed JSON properties. * Strengthen shared JSON helper functions to verify object structure and expected value types before accessing strings, integers, objects, or arrays. * Treat incomplete upload responses as failures rather than persisting invalid item data. * Fail safely through the existing skip, retry, return, or failure paths when malformed responses are received. * Correct the generated fake folder response used by test and dry-run processing. Validation completed: * All GitHub Actions E2E account suites passed, including Personal, Business, SharePoint, shared-folder, and 15-character drive-ID testing. * OpenBSD monitor mode completed more than 24 hours of continuous filesystem churn without a crash or processing failure. * The scheduled 24-hour garbage-collection path executed successfully. * Normal WebSocket delta processing, local deletion propagation, remote directory creation, and file uploads continued successfully after the scheduled cleanup. * Resident memory remained stable during the long-running OpenBSD monitor test. | 2 个月前 | |
Update usage.md and known-issues.md regarding AADSTS70000 errors (#3615) * Add detailed guidance to usage and known-issues documentation explaining AADSTS70000 errors during authentication. Clarifies that these failures are caused by invalid or expired authorisation codes, commonly due to browser extensions or privacy features modifying the redirect URI, and documents recommended remediation steps. * Fix 'OneDrive Free Client' as this should read 'OneDrive Client for Linux' | 8 个月前 | |
OneDrive Client for Linux v2.5.0 (#2805) OneDrive Client for Linux v2.5.0 --------- Signed-off-by: Thomas Staudinger <Staudi.Kaos@gmail.com> Co-authored-by: JC-comp <147694781+JC-comp@users.noreply.github.com> Co-authored-by: Dimitri Papadopoulos Orfanos <3234522+DimitriPapadopoulos@users.noreply.github.com> Co-authored-by: Pierrick Caillon <megamisan@users.noreply.github.com> Co-authored-by: Pierrick Caillon <pierrick.caillon@megami.fr> Co-authored-by: Thomas Staudinger <Staudi.Kaos@gmail.com> Co-authored-by: Yuan Liu <Lyncredible@users.noreply.github.com> | 2 年前 | |
Correct Docker documentation (#3605) * Correct Docker documentation as to distribution versions being used for the Docker images. This should have been updated with the December 2025 update | 8 个月前 | |
Update Security Documents (#2484) * Update Security Documents | 3 年前 | |
Add Server Side Filtering Documentation (#3663) * Add Server Side Filtering Documentation | 6 个月前 | |
Release files for 2.5.11 (#3764) * Add the missing `remove_source_folders` entry to `--display-config` output. * Release files for 2.5.11 | 3 个月前 | |
Update Documentation (#3510) * Update Documentation | 10 个月前 | |
Update ubuntu-package-install.md (#3721) * Remove Ubuntu 25.04 as supported platform | 4 个月前 | |
Add project sponsorship visibility to initial graphical authentication (#3867) ## Summary This PR adds restrained GitHub Sponsors visibility to the OneDrive Client for Linux while deliberately avoiding recurring or intrusive sponsorship messaging. Following a successful **initial graphical authentication**, the browser completion page now includes an optional invitation to help sustain the project through GitHub Sponsors. The sponsorship message is not displayed during `--reauth`, authentication failures, application startup, monitor startup, normal synchronisation activity, terminal output or desktop notifications. ## Changes - Enhances the graphical authentication completion page with a clearer responsive layout and application identity. - Displays the sponsorship section only after successful initial graphical authentication. - Does not display sponsorship content during explicit `--reauth`. - Adds an attributable GitHub Sponsors link using GitHub Sponsors campaign metadata. - Adds passive sponsorship information to the project README and graphical-authentication documentation. - Adds browser response protections including `Referrer-Policy: no-referrer`, `Cache-Control: no-store`, a restrictive Content Security Policy and `X-Content-Type-Options: nosniff`. - Does not add application telemetry, click tracking or any new configuration option. ## Sponsorship Behaviour The graphical authentication page displays: > Help sustain OneDrive Client for Linux OneDrive Client for Linux is free, open-source software that is independently developed and maintained. If it is useful to you or your organisation, you can help sustain ongoing development, testing and maintenance through GitHub Sponsors. The user must explicitly select **Sponsor on GitHub** before any connection to GitHub is made. GitHub Sponsors campaign metadata is used only to attribute completed sponsorships to the relevant project surface. ## Privacy The application does not report whether the sponsorship message was displayed or selected. No application telemetry or analytics have been added. The local OAuth completion response explicitly prevents the Microsoft OAuth callback URL from being supplied as a browser referrer when following the external sponsorship link. | 24 天前 | |
Fix spelling problems as identified by GitHub Action check-spelling (#2946) * Fix spelling problems as identified by GitHub Action check-spelling | 1 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 24 天前 | ||
| 21 天前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 21 天前 | ||
| 5 个月前 | ||
| 8 个月前 | ||
| 20 天前 | ||
| 2 个月前 | ||
| 8 个月前 | ||
| 2 年前 | ||
| 8 个月前 | ||
| 3 年前 | ||
| 6 个月前 | ||
| 3 个月前 | ||
| 10 个月前 | ||
| 4 个月前 | ||
| 24 天前 | ||
| 1 年前 |