commit 0737599cd4b4ecd74b37721a401b0891d04bb6f6
Author: Nick Craig-Wood <nick@craig-wood.com>
Date:   Tue Apr 28 10:57:02 2026 +0100

    protondrive: fix segfault when copying files missing revision metadata
    
    When a Proton Drive file has no active revision attributes,
    readMetaDataForLink returns a nil FileSystemAttrs and Object.originalSize
    is left as nil. Object.Open then dereferenced this nil pointer when
    calling fs.FixRangeOption, causing a SIGSEGV during copy.
    
    Use Object.Size() instead, which already implements the correct fallback
    to the link size when originalSize is unavailable.
    
    This updates the github.com/rclone/Proton-API-Bridge package to fix a
    segfault when reading files with no metadata.
    
    Fixes #9377
    Fixes #9117

commit 3b2011c7a09fc32d8a62036891bbd47a36175e4d
Author: Nick Craig-Wood <nick@craig-wood.com>
Date:   Mon May 4 18:25:56 2026 +0100

    protondrive: route library logging through rclone's logger
    
    Previously all log output produced by Proton-API-Bridge (stdlib log)
    and go-proton-api (logrus + resty's logger) bypassed rclone's
    logging: it ignored -v / -vv levels and didn't reach --log-file.
    
    Add a small adapter implementing the resty.Logger / bridge Logger
    shape that calls fs.Errorf / fs.Logf / fs.Debugf, and pass it via
    the new Config.Logger hook. The bridge in turn forwards the same
    value to go-proton-api's WithLogger option, so HTTP-layer warnings
    and the formerly-hardcoded logrus warnings inside go-proton-api
    also surface through rclone's log levels.

commit ef26e6d26d3b6ccb989fe69e2c78eb8fe707b88d
Author: Nick Craig-Wood <nick@craig-wood.com>
Date:   Mon May 4 18:19:10 2026 +0100

    protondrive: route HTTP through rclone's transport
    
    The Proton Drive backend constructed the upstream Proton-API-Bridge
    without ever passing rclone's HTTP transport. As a result none of
    rclone's HTTP flags reached Proton: --dump headers, --dump bodies,
    --no-check-certificate, --user-agent, --bind, --ca-cert, --header,
    --tpslimit etc. all silently did nothing for this remote, and HTTP
    traffic was invisible to -vv.
    
    Pass fshttp.NewTransport(ctx) through the new Config.Transport hook on
    the bridge, which forwards it to the updated go-proton-api's
    WithTransport option and so to the underlying resty client.

commit c0a8b2597d6957c4ffe88174fa2038b6a3b82b32
Author: Nick Craig-Wood <nick@craig-wood.com>
Date:   Tue May 5 09:43:22 2026 +0100

    Add Copilot to contributors

commit 74d65bf670503d26ca1b2c5fe163859e558d269b
Author: Nick Craig-Wood <nick@craig-wood.com>
Date:   Tue May 5 09:43:22 2026 +0100

    Add Sven Rebhan to contributors

commit a4e647664221c84861bdbf66f9f73640efce53f9
Author: Nick Craig-Wood <nick@craig-wood.com>
Date:   Tue May 5 09:43:22 2026 +0100

    Add Gustavo V. F. to contributors

commit 6c66b4985dbc4b8eeaa4a239de133897aa56c30a
Author: Nick Craig-Wood <nick@craig-wood.com>
Date:   Tue May 5 09:43:22 2026 +0100

    Add 王一赫 to contributors

commit b8b3346499139ead43474530bbac8ab2ef542492
Author: Sven Rebhan <36194019+srebhan@users.noreply.github.com>
Date:   Mon May 4 12:06:30 2026 +0200

    log: fix side effects when importing rclone as a library
    
    Avoid side effects by using own logger instance
    
    - Importing fs/log only sets rclone's private logger via fs.SetLogger,
      so internal rclone logging works from the moment the package is
      imported but the process-wide slog default is left untouched.
    
    - slog.SetDefault and slog.SetLogLoggerLevel move into InitLogging,
      which is called explicitly from the CLI (cmd/cmd.go), the librclone
      wrapper and the integration test framework. So rclone-as-a-program
      keeps capturing log.Print/log.Fatal and slog.Default() output as
      before.
    
    Library consumers that import fs/log without calling InitLogging now
    keep their own slog default and can safely route rclone output back
    into it via log.Handler.SetOutput without recursing.
    
    Fixes #8907
    
    Co-authored-by: Nick Craig-Wood <nick@craig-wood.com>

commit 9f89102a574c841dbb00f2e8acdaa77c1b3b8a60
Author: Gustavo V. F. <31892323+Gustavo-V-F@users.noreply.github.com>
Date:   Sat May 2 12:47:07 2026 -0300

    bisync: fix retryable without --resync error message when --resync has a critical failure

commit 075552367ef240d90aea7f894948ff6485269909
Author: Leon Brocard <acme@astray.com>
Date:   Sat May 2 12:28:30 2026 +0100

    cmd/serve/s3: return object listings in key order
    
    The S3 ListObjects response from `rclone serve s3` was sorting object
    contents by modification time instead of object key. This made the
    listing order incompatible with S3 clients which expect lexicographic
    key ordering.
    
    In particular, `aws s3 sync` assumes both source and destination
    iterators are ordered by key. With the old modtime ordering it could
    misidentify files as missing or outdated and re-download objects that
    were already up to date.
    
    Change the pager to sort returned objects by key and add a regression
    test which uses keys and modtimes arranged so the old behaviour would
    fail.
    
    Fixes #9002

commit ada5559fe115385d28b0db02d85f413ca3c91d51
Author: Nick Craig-Wood <nick@craig-wood.com>
Date:   Fri May 1 17:15:20 2026 +0100

    Start v1.75.0-DEV development
