v1.0.1

Added

• Every release archive now names the platform it was built for, in a
  PLATFORM-<platform>.txt at its root and in the pluginst.inf description
  Double Commander shows when installing a plugin straight from the zip. An
  unpacked archive used to be indistinguishable from the other two: all of them
  hold a file called fsplugin.wfx64, and the zip name was the only thing that
  ever said linux or macos. tests/test_package.sh covers this, along with
  the older invariant it must not break — pluginst.inf sits at the archive
  root, or Double Commander stops recognising the zip as an installable plugin.
• install.sh checks that the plugin is a library this machine can actually
  load before installing it, and refuses a foreign one, naming the archive to
  download instead. Every release archive contains a file called
  fsplugin.wfx64, so downloading the Linux one on a Mac — aarch64 reads as
  "Apple Silicon" easily enough — used to install cleanly and fail much later,
  inside Double Commander, as the unhelpful "This is not a valid plugin!". The
  file format is fatal; a Mach-O built for the other architecture is only a
  warning, since it still loads under Rosetta.
• install.sh now finishes the install instead of stopping halfway: it
  registers the plugin in doublecmd.xml as ADB rather than printing the
  GUI steps and leaving the rest to the reader. The XML editing lives in
  scripts/register_plugin.py (python3, standard library only), which is
  idempotent — a re-install updates the existing entry instead of adding a
  second one — and backs the configuration up first.
• install.sh --no-register for the old behaviour: copy the plugin file and
  nothing else.
• install.sh refuses to register while Double Commander is running, since DC
  rewrites doublecmd.xml on exit and would discard the change. When it cannot
  register for any other reason — no python3, or Double Commander has never
  been started and so has no configuration file yet — it prints the manual
  steps and the exact XML block instead of failing quietly.
• install.sh also looks for the configuration inside Flatpak and Snap
  sandboxes on Linux.
• tests/test_install.sh, run as part of ./run_tests.sh. It covers the
  registrar against synthetic configurations — including the case that makes
  naive matching dangerous: Double Commander's own MTP plugin is also called
  fsplugin.wfx64, so a registration keyed on the file name alone would
  rewrite the user's MTP entry.

---

Which file do I want?

Archive	For
adb-wfx-*-macos-universal.zip	macOS, Apple silicon and Intel
adb-wfx-*-linux-x86_64.zip	Linux on x86_64
adb-wfx-*-linux-aarch64.zip	Linux on ARM64

Verify a download against SHA256SUMS, then follow the Installing section of
the README. Copying the file into place is not enough on its own — the plugin
also has to be registered in Double Commander's own configuration.

macOS: clear the quarantine attribute after unzipping, or the plugin will not
load:

xattr -dr com.apple.quarantine fsplugin.wfx64

Linux builds are untested on real hardware. They compile and pass the full
unit suite in CI on both architectures, but nobody has yet run them against an
actual Android device inside Double Commander — unlike the macOS build, which is
hardware-confirmed on a Pixel 7. Reports either way are very welcome; please open
an issue.

Windows / Total Commander are not supported yet.

v1.0.0

First public release.

Added

• WFX file-system plugin for Double Commander that browses Android devices over
  ADB, speaking the adb server's wire protocol directly (host:, sync v1 and
  shell: services) instead of shelling out to the adb command line for every
  operation.
• Devices appear under a virtual ADB root as <model> (<serial>).
• Upload and download with the real modification time preserved in both
  directions — the reason this plugin exists, since MTP stamps uploads with the
  moment of the copy and offers no way to correct it.
• Delete, rename/move, copy within one device, and create directory.
• FsSetTimeW, wired to Double Commander's own "change date" UI. It is also
  load-bearing for a DC quirk: DC strips its internal caoCopyTime flag from
  every copy — downloads included — unless a plugin exports FsSetTime or
  FsSetTimeW (doublecmd#3051).
• Correct handling of filenames with spaces, quotes, non-ASCII characters and
  literal shell metacharacters: every path sent to the device's shell is
  single-quoted first.
• Directory-listing cache with a short TTL and a mutex, so stepping back into a
  directory you just left costs no round trip.
• Cancellable transfers, socket timeouts with a stall hook, and bounded
  wire-driven allocations.
• Unit suite of 880+ checks running against a fake transport (no device needed),
  an export-table check, an opt-in end-to-end suite against real hardware
  (tests/device_test.sh) and a benchmark against adb push/adb pull
  (tests/bench.sh).
• Builds for macOS (arm64, x86_64, universal) and Linux (x86_64, aarch64).

Known limitations

See the README for the full list. In brief: sync protocol v1 only (32-bit mtime,
so no dates past 2038; 32-bit size, so no files ≥ 4 GiB), single-threaded use
only, permission-denied directories are indistinguishable from empty ones, and
F6 to or from a local disk is refused by Double Commander itself before the
plugin is asked to do anything.

---

Which file do I want?

Archive	For
adb-wfx-*-macos-universal.zip	macOS, Apple silicon and Intel
adb-wfx-*-linux-x86_64.zip	Linux on x86_64
adb-wfx-*-linux-aarch64.zip	Linux on ARM64

Verify a download against SHA256SUMS, then follow the Installing section of
the README. Copying the file into place is not enough on its own — the plugin
also has to be registered in Double Commander's own configuration.

macOS: clear the quarantine attribute after unzipping, or the plugin will not
load:

xattr -dr com.apple.quarantine fsplugin.wfx64

Linux builds are untested on real hardware. They compile and pass the full
unit suite in CI on both architectures, but nobody has yet run them against an
actual Android device inside Double Commander — unlike the macOS build, which is
hardware-confirmed on a Pixel 7. Reports either way are very welcome; please open
an issue.

Windows / Total Commander are not supported yet.