2 Commits

Include renames

Author	SHA1	Message	Date
jaap-jan	04faef6597	Move files to and from a host over SFTP ... M2's file transfer, built bottom-up: an SFTP session on the SSH layer, a transfer queue in a project of its own, and the two-pane browser the design asked for replacing the screen that said it did not exist. Remote listings carry names, sizes, modification times and a real drwxr-xr-x — nothing in this repository could render a POSIX mode before — and the queue moves one file at a time with progress, throughput and resume. The design import assumed this would be an SFTP subsystem channel on ISshConnection, beside the shell on a transport that is already up. SSH.NET does not offer that: SftpClient derives from BaseClient and owns its own transport, and there is no supported way to hand it an SshClient's session. So file transfer opens a second authenticated connection, and it is named for that rather than dressed up as a channel — OpenSftpAsync is on ISftpSessionFactory, not on a connection. The difference is visible to a user: the host records a second login, and a host whose password is typed each time asks for it again on this screen. It goes through the same host key gate, the same pin and the same two refusals a shell does, so a fingerprint approved for a terminal is approved here and one approved here reaches the other machines with the next sync. docs/design-import-gaps.md is corrected, and marked as the one row where what shipped differs from what it predicted. Nothing is written at its final name until it is complete. Every transfer goes to a .dodossh-part file beside its destination and is renamed into place at the end, so an interrupted transfer can never be mistaken for a finished one — which matters most for what this screen is actually for, which is copying a build artefact onto a server and then running it. A destination that already exists is refused outright rather than overwritten: the queue has no way to ask, and silently replacing a file somebody's process is serving is the worse of the two failures. The remote pane has DELETE and MKDIR so that refusal is not a dead end. A test against the container pins the assumption underneath all of this — that SFTP's rename does not clobber. Resume works within a run of the application and not across a restart, and the limit is deliberate rather than unfinished. Nothing records which source wrote a part file, and resuming one on the strength of its name matching is how a corrupt artefact gets delivered with nothing reporting a failure; a part file found at startup is started over. Making it survive a restart needs the preferences store this client still has not got. The offset a resume starts at is the part file's own length rather than the transfer's recorded progress: a cancellation can land between a write completing and the counter moving, and only one of those two is a fact about the bytes that are there. The queue and its connection outlive a lock, as shells do. LockAsync already argues that locking must not destroy work in flight — it is what somebody does when they walk away from the machine, which is exactly when a long transfer is most likely to be running — so TransfersViewModel is created once and the vault is attached on unlock and detached on lock. What locking takes is the host list, and it has to: those rows carry decrypted secrets. DodoSSH.Client.Transfer is a new project rather than more of Client.Ssh. The two answer different questions — one is about reaching a host, the other about moving bytes and what to do when moving them stops halfway — and this is the only client project that deliberately touches the local filesystem. Three defects the tests found, none of which review would have. SftpPath.Name answered an empty string for the root. NavigateRemoteAsync wrapped itself in the busy guard, so navigating from inside another command did nothing at all and the remote pane simply stayed empty after connecting, with no failure anywhere to explain it. And opening an SFTP session per test made two handshakes per test — this client learns a host key by being refused — which pushed the SSH assembly past sshd's MaxStartups and failed a different few unrelated tests each run; the session is shared through the fixture now, with the reason written where the next person will hit it. 1004 tests green across 18 projects, 24 of them new: the SFTP subsystem against the OpenSSH container, the queue against a real temporary directory and a fake host, and three more layout measurements because a screen this window has never laid out is a screen never checked. Not verified: the screen has not been looked at running. The layout harness measures it at the window's minimum in three shapes, which is the class of defect that has shipped here before, but reaching it in the application needs the compose stack, the migrations, the API and a browser sign-in. What is still absent — the status bar's transfer count, dragging between the panes, transferring a directory, and sftp over a bastion — is in docs/design-import-gaps.md.	2026-07-31 11:07:29 +02:00
jaap-jan	dbddbcd711	Hand the terminal the keyboard on connect, and take it back on lock ... After a successful connect the first keystrokes went to the shell's UI rather than the remote shell. The page's own term.focus() focuses the textarea inside the document, which does nothing while the window's keyboard focus is still on the Connect button, so the terminal had to be clicked before it would accept anything. The obvious guess about the fix — that reaching a native child window needs SetFocus through P/Invoke — is backwards, and measuring it first is what kept this small. NativeWebView overrides Focusable to true and its OnGotFocus calls the adapter's Focus(), which on Windows is ICoreWebView2Controller::MoveFocus(PROGRAMMATIC). So a plain Avalonia Terminal.Focus() really does move Win32 focus into WebView2. Measured in a standalone harness with no DodoSSH code, on the same 340,* grid as the shell, reporting GetFocus() and the page's own document.hasFocus() at each step: focus lands on the Chrome_WidgetWin_1 child and the page reports hasFocus: true. It is the return trip the package does not implement. OnLostFocus calls the adapter's ResignFocus(), and on Windows that method body is empty, so Avalonia's focus and Win32's diverge: after textBox.Focus() the focused element is the text box while the keyboard is still on WebView2 — a caret that silently receives nothing. Window.Activate() and Window.Focus() were both measured and neither recovers it, so the hand-back is a SetFocus on the top-level, in Views/NativeKeyboardFocus.cs. A real mouse click does recover it, because Avalonia's window sets focus on pointer input, which is why this is invisible to anyone who clicks before typing. That turned up a worse defect than the one being fixed, and it shipped in 0500e43. Collapsing the WebView does not release the keyboard: focus stays on the hidden holder — measured held by a window reporting visible=False — while Avalonia's focused element becomes (none). So a user who had clicked the terminal and then pressed Lock got an unlock screen that swallowed the passphrase. Locking now hands the keyboard back and focuses that box. Ctrl+Shift+F6 is the way out for someone using only a keyboard. It has to be handled in terminal.js and posted to the host as a web message, because once the child window owns Win32 focus Avalonia receives no key events and no KeyBinding could fire; the package also subscribes MoveFocusRequested and discards it, so there is no Tab-out to lean on. Not Escape, which vim alone rules out, and not a bare F6, which TUIs bind — Ctrl+Shift is the range terminal emulators conventionally keep for themselves and never forward to the remote. Verified rather than assumed: the posted string arrives verbatim in Body, and the chord reaches the page as F6 with both modifiers. Order matters and is now recorded. Focus() on a collapsed control is a measured no-op and is not replayed when it is revealed, so focus survives a lock/unlock cycle only because a session can be opened solely from an unlocked vault, which is what reveals the control in the first place. The view models still reference no view. VaultViewModel raises SessionOpened on the success path only, the shell forwards it as TerminalSessionOpened through the generated OnVaultChanged hook so unlock, lock and dispose all attach and detach in one place, and the view holds the whole focus policy. An event rather than a bound flag because connecting a second host while one is open has to move focus again, and no state change describes that. Three tests, and what they do not cover is the point. They cover the plumbing: focus is asked for once per session, a failed connect does not ask at all — a host-key prompt needs the keyboard on its own buttons — and locking stops the forwarding. They cannot cover the focus call, because headless Avalonia has no native window, so a headless test would focus correctly and confirm the wrong belief; that is measured in the harness and written down in docs instead. Dropping the forwarding fails two of them and dropping the detach fails one; deleting the raise outright does not compile, since the event would be unused. Reaching the connect path at all needed two new fakes. FakeRenderer attaches the way the real page does — fetch the served page, read back the token and socket URL the host substituted into it, then open the socket with both subprotocols — rather than being handed the token, so the part of the handshake that has been got wrong before stays under test. FakeSsh replaces a factory that would need a reachable sshd, which DodoSSH.Client.Ssh.Tests already covers against a container. The suite also never called workspace.Start(), so nothing served the page and no renderer could have attached. DllImport rather than the source-generated LibraryImport, which requires AllowUnsafeBlocks for the whole project. The signature is blittable so there is no marshalling stub to improve on, and turning unsafe code on across a client that handles key material to gain nothing is a poor trade. Correcting an earlier entry: docs/platform-flags.md described this as a focus-plumbing gap and offered "click inside the terminal first" as the workaround. Both true, and both stop short of the half that matters — focus crosses into the WebView readily and never comes back on its own, which is the same mechanism as the text boxes that mysteriously stopped accepting keystrokes in the airspace entry above it, not a separate fault.	2026-07-29 14:31:09 +02:00