Type a path on the SFTP pane, and put a file right without deleting it

Three things the file browser could not do. Somewhere to go had to be walked
to, a file that landed under the wrong name could only be removed and sent
again, and the listing went on showing the directory as it was before this
application put something in it.

◆ THE PATH IS A BOX NOW, not a TextBlock printing where the pane was. A
breadcrumb only reaches what is under the directory already listed, so crossing
a host's filesystem cost a click and a round trip a level, and a path somebody
already knew could not be entered at all. Enter goes; Escape puts back what the
pane is really showing.

What is typed may be absolute, relative to the directory showing, or start at
~ — the four shapes a shell takes, because somebody typing into a box is typing
what they would type into a shell. SftpPath.Resolve turns all of them into one
absolute path, and it resolves them here rather than handing a relative path to
the server: the server would resolve it against the session's own working
directory, which is not necessarily the directory the breadcrumb above the box
is showing. `..` is collapsed textually, which differs from cd through a
symbolic link; the alternative is a realpath round trip before anything lists.

The box holds its own value rather than RemotePath itself. Binding it straight
to the path would navigate on every keystroke — `/`, then `/v`, then `/va` — a
round trip and a failed listing per character. Every other way of moving writes
the real path back into it; a refused listing deliberately does not, because
the path that did not resolve is the one worth having in front of you.

◆ RENAME AND MOVE, and DELETE moves to join them. It had been sitting in the
pane header beside UP and REFRESH — two things that move the pane and one that
destroys a file, in one row — and the three that act on the selected row are
now together in a row of their own, under the name of the row they are about.

One SFTP rename underneath both new operations and two separate questions on
the screen, because the answer is a different kind of thing each time: a rename
takes a name and must not take a path, a move takes a directory and must not
take a name. One box asking for a destination path would be fewer controls and
a worse question — the two mistakes it invites are exactly the ones the split
makes impossible. Each form opens on the answer that changes nothing, so what
gets edited is the half somebody came to change.

Three refusals are made here, and they are the ones a server's message would
not explain: a separator in a name (no such file, about a directory nobody
meant to name), a destination equal to the source (success, and a file that did
not move), and a directory into itself (EINVAL, true and useless). Everything
else is the server's — a name already taken, a path that is not there, a mount
that cannot be crossed — and arrives in the status line in its own words.
Neither is painted in the deletion card's red: a rename is undone by renaming
back, and spending that red twice makes it stop meaning anything.

◆ THE LISTING REFRESHES ITSELF when a transfer lands in it. Both panes, since
an upload lands on the host and a download lands here and either leaves the
pane that is showing that directory a step behind. Only the directory actually
on screen: a queue moving a hundred files elsewhere must not be a round trip
per file for a listing nobody is looking at.

It waits rather than interrupting. Another operation running would have two
listings racing for one collection, and re-listing under an open question is
how the row somebody answered about stops being the row that gets acted on — so
the staleness is remembered and settled at the end of the operation or when the
question is dismissed. It says nothing either way: nobody asked for it, and the
status line at that moment is carrying the news about the transfer. The
selection survives, re-found by path, which is what makes an unasked-for
refresh safe to run under somebody's pointer at all.

◆ THE LAYOUT SUITE FOUND A REAL FAULT and the fix is where the height goes. The
rename form did not fit the 204 pixels the session shell's own sidebar leaves
this pane — MKDIR and the listing were pushed off the bottom. The form is
shorter now (the placeholder says what the box wants, so there is no field
label above it), and the item row and the breadcrumb step aside while any of
the three questions is up, which is what the phone head already did with its
own buttons.

Measuring also settled something the markup had been claiming and is not true:
at that width the listing collapses to nothing under any of the three cards,
the deletion card included, and has done since the sidebar arrived. So "the row
it is about is still on screen" is retired from the deletion card's remark, and
the full path each card carries is what identifies the row instead. Recorded
where it is drawn rather than left to be rediscovered.

TESTS. SftpPath.Resolve gets the four shapes, ~ with and without a home to
expand it to, a blank box, and climbing past the root. ShellFlowTests gets nine
against a session that records what it was asked to do — which path was
renamed, which directories were listed — rather than against the sentence this
code writes about itself: the path box absolute and relative, rename in place,
the separator refusal, a move by relative path, the no-op refusal, the three
questions displacing each other, and the three rules the automatic refresh
follows. The local half is in TransferQueueingTests, where a real folder
answers. Two new shapes are measured, and the deletion card's own measurement
moves to the connected state — the only state it can be asked in, and the
narrow one.

What the tests cannot reach is in docs/manual-checks.md as phase 2b: a real
server's cross-device and name-taken refusals, and a soft keyboard, which is
why the phone's path box has a GO button rather than trusting whatever the IME
decided to draw on its return key.

src/DodoSSH.Client.Shell/ViewModels/TransfersViewModel.cs

@@ -306,6 +306,83 @@ internal sealed record RemoteDeletionRequest(string Name, string FullPath, bool
             + "touched, and there is no undo.";
 }
 
+/// <summary>Which of the two things a rename actually is, from where the user is standing.</summary>
+/// <remarks>
+/// One SFTP operation underneath — <c>ISftpSession.RenameAsync</c> is the whole of both — and two separate
+/// questions on the screen, because the answer a person types is a different kind of thing each time. A
+/// rename takes a name and must not take a path; a move takes a directory and must not take a name. Folding
+/// them into one box asking for a destination path would be fewer controls and a worse question: the two
+/// mistakes it invites — typing a directory where a name goes, or a name where a directory goes — are
+/// exactly the ones this split makes impossible to make.
+/// </remarks>
+internal enum RemoteMoveKind
+{
+    /// <summary>Same directory, different name.</summary>
+    Rename,
+
+    /// <summary>Same name, different directory.</summary>
+    Move,
+}
+
+/// <summary>
+/// Something on the host that is being given a new name or a new home, and has not been committed yet.
+/// </summary>
+/// <remarks>
+/// <para>
+/// The shape <see cref="RemoteDeletionRequest"/> already established, and here for the same reason: it
+/// carries the full path rather than the name, so nothing that happens between opening the form and
+/// pressing its button can point the operation at a different file. The selection can move underneath it —
+/// a refresh nulls it — and the request stays about what was asked about.
+/// </para>
+/// <para>
+/// <b>It asks rather than warns.</b> Renaming and moving on the host are not deletions: what they change is
+/// where the bytes are reached from, and both are undone by doing them again the other way. So this form
+/// carries a field and a verb instead of <see cref="RemoteDeletionRequest.Consequence"/>'s "there is no
+/// undo" — the one warning on this screen that is earned, and worth not spending twice.
+/// </para>
+/// </remarks>
+/// <param name="Name">What the row is called now.</param>
+/// <param name="FullPath">Where it is now, which is the end of the operation nothing may re-point.</param>
+/// <param name="IsDirectory">Whether it is a directory, which changes what moving it can be asked to do.</param>
+/// <param name="Kind">Which question is being asked.</param>
+internal sealed record RemoteMoveRequest(string Name, string FullPath, bool IsDirectory, RemoteMoveKind Kind)
+{
+    /// <summary>Whether this is the rename question rather than the move one.</summary>
+    internal bool IsRename => Kind is RemoteMoveKind.Rename;
+
+    /// <summary>The heading, which names the thing rather than only the verb.</summary>
+    internal string Question => IsRename
+        ? $"Rename '{Name}' on the host"
+        : $"Move '{Name}' to another directory";
+
+    /// <summary>
+    /// What an empty box shows, which is the shape of the answer rather than an example of one.
+    /// </summary>
+    /// <remarks>
+    /// The placeholder is the whole of what says which of the two kinds of answer the box wants — there is
+    /// no label above it. A field label would be a second line saying what this line already says, and the
+    /// pane this form opens in is 204 pixels wide inside the session shell: every line it does not need is
+    /// a line of the listing underneath that survives.
+    /// </remarks>
+    internal string FieldHint => IsRename ? "new name" : "/path/to/directory";
+
+    /// <summary>What the button that commits it says.</summary>
+    internal string ConfirmLabel => IsRename ? "RENAME" : "MOVE";
+
+    /// <summary>
+    /// What it does, in the one sentence the form has room for.
+    /// </summary>
+    /// <remarks>
+    /// Both halves state the refusal rather than the action, because the action is already in the heading
+    /// and the refusal is the part nobody expects: SFTP's rename does not replace, so a name already taken
+    /// is a failure rather than a silent overwrite — which is the same promise the transfer queue makes and
+    /// rests on the same server behaviour.
+    /// </remarks>
+    internal string Note => IsRename
+        ? "A name already taken is refused, not overwritten."
+        : "Relative to the directory showing. A name already taken is refused, not overwritten.";
+}
+
 /// <summary>
 /// The transfers screen: a host, two directory panes, and the queue between them.
 /// </summary>
@@ -382,6 +459,15 @@ internal sealed partial class TransfersViewModel : ObservableObject, IAsyncDispo
 
     private bool disposed;
 
+    /// <summary>Whether the remote listing on screen is known to be out of date.</summary>
+    /// <remarks>
+    /// Set by <see cref="NoteTransferLanded"/> and cleared by any listing of the directory it is about.
+    /// Read back by <see cref="RemoteListingIsStale"/>, which exists so that the deferral this drives can be
+    /// asserted on in the state where it defers — the moment a transfer lands over an open question is not
+    /// one a test can otherwise see the inside of.
+    /// </remarks>
+    private bool remoteListingIsStale;
+
     /// <param name="sftp">Opens SFTP sessions.</param>
     /// <param name="clock">Time source, for transfer rates and timestamps.</param>
     /// <param name="post">
@@ -706,6 +792,26 @@ internal sealed partial class TransfersViewModel : ObservableObject, IAsyncDispo
 
     internal ObservableCollection<CrumbViewModel> RemoteTrail { get; } = [];
 
+    /// <summary>
+    /// What is in the pane's path box, which is not where the pane is.
+    /// </summary>
+    /// <remarks>
+    /// <para>
+    /// A draft beside <see cref="RemotePath"/> rather than the path itself made editable, and the two facts
+    /// really are different: <see cref="RemotePath"/> is the directory that was listed, and this is what
+    /// somebody is halfway through typing. Binding the box straight to the path would navigate on every
+    /// keystroke — <c>/</c>, then <c>/v</c>, then <c>/va</c> — which is a round trip and a failed listing
+    /// per character.
+    /// </para>
+    /// <para>
+    /// It is written back from <see cref="ListRemoteAsync"/>, so every other way of moving — a breadcrumb,
+    /// UP, a pin, connecting — puts the real path back in the box. What a failed listing leaves is what was
+    /// typed, on purpose: the path that did not resolve is the one worth having in front of you to correct.
+    /// </para>
+    /// </remarks>
+    [ObservableProperty]
+    private string remotePathDraft = string.Empty;
+
     [ObservableProperty]
     private RemoteEntryRowViewModel? selectedRemoteEntry;
 
@@ -721,13 +827,75 @@ internal sealed partial class TransfersViewModel : ObservableObject, IAsyncDispo
 
     internal bool IsConfirmingRemoteDeletion => PendingRemoteDeletion is not null;
 
+    /// <summary>The rename or move being filled in, or null when none is.</summary>
+    [ObservableProperty]
+    private RemoteMoveRequest? pendingRemoteMove;
+
+    /// <summary>
+    /// What has been typed into whichever of the two forms is open — a name, or a directory.
+    /// </summary>
+    /// <remarks>
+    /// One box for both, because only one of the two forms is ever open: they replace each other, and a
+    /// second field would be a second thing to clear at every place this one is. Seeded from the row when
+    /// the form opens — the current name for a rename, the current directory for a move — so that both
+    /// questions start from the answer that changes nothing, and what somebody edits is the part they came
+    /// to change.
+    /// </remarks>
+    [ObservableProperty]
+    private string remoteMoveTarget = string.Empty;
+
+    internal bool IsMovingRemote => PendingRemoteMove is not null;
+
+    /// <summary>
+    /// Whether the pane is waiting on an answer about the selected row.
+    /// </summary>
+    /// <remarks>
+    /// The three item buttons and the automatic refresh all read this rather than the two flags separately.
+    /// Deleting, renaming and moving are one at a time by construction — each form's own opening clears the
+    /// other — and what this names is the state where none of them may be started and nothing may pull the
+    /// listing out from under the question. See <see cref="SettleRemoteListingAsync"/>.
+    /// </remarks>
+    internal bool IsAskingAboutRemoteEntry => IsConfirmingRemoteDeletion || IsMovingRemote;
+
     /// <summary>Whether the pane's DELETE is live.</summary>
     /// <remarks>
-    /// Off while its own question is up, so a second press cannot arm a second one behind the card — and
-    /// disabled rather than hidden, because this button sits in a row of three and a gap where it was would
-    /// move UP and REFRESH out from under the pointer.
+    /// Off while any of the three questions is up, so a second press cannot arm a second one behind the
+    /// form — and disabled rather than hidden, because these buttons sit in a row and a gap where one was
+    /// would move the other two out from under the pointer.
     /// </remarks>
-    internal bool CanDeleteRemote => IsConnected && !IsConfirmingRemoteDeletion;
+    internal bool CanDeleteRemote => IsConnected && !IsAskingAboutRemoteEntry;
+
+    /// <inheritdoc cref="CanDeleteRemote" />
+    internal bool CanRenameRemote => CanDeleteRemote;
+
+    /// <inheritdoc cref="CanDeleteRemote" />
+    internal bool CanMoveRemote => CanDeleteRemote;
+
+    /// <summary>
+    /// Whether the pane shows the row of things that can be done to the chosen row.
+    /// </summary>
+    /// <remarks>
+    /// Gone while one of the three questions is up, rather than merely disabled, and the phone head does
+    /// the same with its own buttons for the same reason: the form is the answer to the question those
+    /// buttons ask, and a pane 204 pixels wide inside the session shell has to spend the height on one or
+    /// the other. What is not on screen is not a control somebody can press by mistake either.
+    /// </remarks>
+    internal bool ShowsRemoteItemActions => IsConnected && !IsAskingAboutRemoteEntry;
+
+    /// <summary>Whether a transfer has landed in the directory showing and it has not been re-read yet.</summary>
+    /// <remarks>See <see cref="SettleRemoteListingAsync"/> for when that is allowed to be true for a while.</remarks>
+    internal bool RemoteListingIsStale => remoteListingIsStale;
+
+    /// <summary>
+    /// What the item row says it is about — the chosen row's name, or the sentence that says to choose one.
+    /// </summary>
+    /// <remarks>
+    /// A name rather than a full path, unlike the questions the buttons open: this line sits directly above
+    /// the listing with the row it names highlighted in it, so the disambiguation a confirmation needs is
+    /// already on screen. The forms carry the path, because by then the answer is being committed rather
+    /// than merely looked at.
+    /// </remarks>
+    internal string SelectedRemoteName => SelectedRemoteEntry?.Name ?? "Choose a row to act on it";
 
     // ---- The local pane ----
 
@@ -1199,6 +1367,58 @@ internal sealed partial class TransfersViewModel : ObservableObject, IAsyncDispo
         }
     }
 
+    /// <summary>
+    /// Goes wherever the path box says.
+    /// </summary>
+    /// <remarks>
+    /// <para>
+    /// The way out of the breadcrumb's own limit: it can only offer what is under the directory already
+    /// listed, so crossing the filesystem meant walking down to the root and back up again, a round trip a
+    /// level. What is typed may be absolute, relative to the directory showing, or start at <c>~</c> — see
+    /// <see cref="SftpPath.Resolve"/>, which is where all three become one absolute path.
+    /// </para>
+    /// <para>
+    /// A blank box is not a request to go to the root. It puts the current path back and stays where it is:
+    /// somebody who cleared the box and pressed Enter has not asked for anything, and <c>/</c> is a long way
+    /// from where they were.
+    /// </para>
+    /// <para>
+    /// Nothing is validated here beyond that. Whether the path exists, is a directory and may be read are
+    /// three questions only the server can answer, and it answers all three at once by refusing the listing
+    /// — which lands in the status line with the server's own words in it.
+    /// </para>
+    /// </remarks>
+    [RelayCommand]
+    private async Task GoToTypedRemotePathAsync(CancellationToken cancellationToken)
+    {
+        if (session is not { } open)
+        {
+            Status = "Connect to a host first.";
+            return;
+        }
+
+        if (RemotePathDraft.Trim().Length == 0)
+        {
+            RemotePathDraft = RemotePath;
+            return;
+        }
+
+        var from = RemotePath.Length > 0 ? RemotePath : open.HomeDirectory;
+
+        await NavigateRemoteAsync(
+            SftpPath.Resolve(from, RemotePathDraft, open.HomeDirectory), cancellationToken)
+            .ConfigureAwait(true);
+    }
+
+    /// <summary>Puts the real path back in the box, for the Escape key.</summary>
+    /// <remarks>
+    /// Half-typed text left in a box that says where you are is a box that is lying about where you are, and
+    /// the pane underneath it goes on showing the directory it always was. Escape is the way out of that
+    /// without having to remember what was in the box before.
+    /// </remarks>
+    [RelayCommand]
+    private void RevertTypedRemotePath() => RemotePathDraft = RemotePath;
+
     /// <summary>
     /// Opens whatever is selected in the remote pane, if it is somewhere to go.
     /// </summary>
@@ -1631,6 +1851,9 @@ internal sealed partial class TransfersViewModel : ObservableObject, IAsyncDispo
             return;
         }
 
+        // The other question goes, so the two forms cannot be on screen at once over one row.
+        PendingRemoteMove = null;
+
         PendingRemoteDeletion = new RemoteDeletionRequest(row.Name, row.FullPath, !row.IsFile);
     }
 
@@ -1666,8 +1889,173 @@ internal sealed partial class TransfersViewModel : ObservableObject, IAsyncDispo
     }
 
     /// <summary>Thinks better of it.</summary>
+    /// <remarks>
+    /// Settles the listing on the way out. A transfer that landed while the question was up left the pane
+    /// out of date and was not allowed to refresh it — see <see cref="SettleRemoteListingAsync"/> — so
+    /// dismissing the question is the moment that refresh becomes safe.
+    /// </remarks>
     [RelayCommand]
-    private void CancelDeleteRemote() => PendingRemoteDeletion = null;
+    private async Task CancelDeleteRemoteAsync()
+    {
+        PendingRemoteDeletion = null;
+
+        await SettleRemoteListingAsync().ConfigureAwait(true);
+    }
+
+    /// <summary>Opens the rename form on the chosen row.</summary>
+    [RelayCommand]
+    private void RenameRemote() => AskAboutMoving(RemoteMoveKind.Rename);
+
+    /// <summary>Opens the move form on the chosen row.</summary>
+    [RelayCommand]
+    private void MoveRemote() => AskAboutMoving(RemoteMoveKind.Move);
+
+    /// <remarks>
+    /// Both forms, because they differ only in what the box starts out holding and what the labels say —
+    /// see <see cref="RemoteMoveRequest"/>. The rename starts from the current name and the move from the
+    /// current directory, so each opens showing the answer that changes nothing and what gets edited is the
+    /// half somebody actually came to change.
+    /// </remarks>
+    private void AskAboutMoving(RemoteMoveKind kind)
+    {
+        if (SelectedRemoteEntry is not { } row)
+        {
+            Status = kind is RemoteMoveKind.Rename
+                ? "Choose something on the host to rename."
+                : "Choose something on the host to move.";
+
+            return;
+        }
+
+        // The other question goes, so the two forms cannot be on screen at once over one row.
+        PendingRemoteDeletion = null;
+
+        PendingRemoteMove = new RemoteMoveRequest(row.Name, row.FullPath, !row.IsFile, kind);
+        RemoteMoveTarget = kind is RemoteMoveKind.Rename
+            ? row.Name
+            : SftpPath.Parent(row.FullPath);
+    }
+
+    /// <summary>
+    /// Carries out whichever of the two was filled in.
+    /// </summary>
+    /// <remarks>
+    /// <para>
+    /// One SFTP rename underneath both, which is what the protocol offers and the whole of what a move is
+    /// on one host. It follows that neither works across hosts and neither works across a filesystem
+    /// boundary on the same host: the server refuses with <c>EXDEV</c>, and that refusal arrives in the
+    /// status line as the server's own sentence rather than being pre-empted by a guess here about which of
+    /// its mounts a path is on.
+    /// </para>
+    /// <para>
+    /// It acts on the path the form named rather than on the selection, for the reason
+    /// <see cref="ConfirmDeleteRemoteAsync"/> does: nothing between opening the form and pressing its button
+    /// may re-point it at a different file.
+    /// </para>
+    /// </remarks>
+    [RelayCommand]
+    private async Task ConfirmMoveRemoteAsync(CancellationToken cancellationToken)
+    {
+        if (PendingRemoteMove is not { } request)
+        {
+            return;
+        }
+
+        if (!TryResolveMoveDestination(request, out var destination, out var refusal))
+        {
+            // The form stays open. What was typed is what has to be corrected, and taking the form away
+            // would take the box holding it as well.
+            Status = refusal;
+            return;
+        }
+
+        PendingRemoteMove = null;
+
+        await RunAsync(
+            request.IsRename ? $"Renaming {request.Name}…" : $"Moving {request.Name}…",
+            async () =>
+            {
+                await RequireSession()
+                    .RenameAsync(request.FullPath, destination, cancellationToken)
+                    .ConfigureAwait(true);
+
+                await ListRemoteAsync(RemotePath, cancellationToken).ConfigureAwait(true);
+
+                Status = request.IsRename
+                    ? $"Renamed {request.Name} to {SftpPath.Name(destination)}."
+                    : $"Moved {request.Name} to {SftpPath.Parent(destination)}.";
+            }).ConfigureAwait(true);
+    }
+
+    /// <summary>Thinks better of it.</summary>
+    /// <inheritdoc cref="CancelDeleteRemoteAsync" path="/remarks" />
+    [RelayCommand]
+    private async Task CancelMoveRemoteAsync()
+    {
+        PendingRemoteMove = null;
+        RemoteMoveTarget = string.Empty;
+
+        await SettleRemoteListingAsync().ConfigureAwait(true);
+    }
+
+    /// <summary>
+    /// Works out where the typed answer actually points, or why it points nowhere.
+    /// </summary>
+    /// <remarks>
+    /// The three refusals here are the ones a server's own error message would not explain. A separator in
+    /// a name is a move wearing a rename's clothing and the server would simply say "no such file" about a
+    /// directory nobody meant to name; a destination equal to the source is a request that succeeds while
+    /// doing nothing; and a directory moved inside itself is <c>EINVAL</c>, which is true and says nothing.
+    /// Everything else — a path that is not there, a name already taken, a mount that cannot be crossed —
+    /// is left to the server, which knows and this does not.
+    /// </remarks>
+    private bool TryResolveMoveDestination(
+        RemoteMoveRequest request, out string destination, out string refusal)
+    {
+        destination = string.Empty;
+        var typed = RemoteMoveTarget.Trim();
+
+        if (typed.Length == 0)
+        {
+            refusal = request.IsRename
+                ? "Type a new name for it."
+                : "Type the directory to move it into.";
+
+            return false;
+        }
+
+        if (request.IsRename)
+        {
+            if (typed.Contains('/', StringComparison.Ordinal))
+            {
+                refusal = "A name cannot contain '/'. Use MOVE to put it in another directory.";
+                return false;
+            }
+
+            destination = SftpPath.Combine(SftpPath.Parent(request.FullPath), typed);
+        }
+        else
+        {
+            var into = SftpPath.Resolve(RemotePath, typed, session?.HomeDirectory);
+            destination = SftpPath.Combine(into, request.Name);
+        }
+
+        if (string.Equals(destination, request.FullPath, StringComparison.Ordinal))
+        {
+            refusal = $"{request.Name} is already there.";
+            return false;
+        }
+
+        if (request.IsDirectory
+            && destination.StartsWith(request.FullPath + "/", StringComparison.Ordinal))
+        {
+            refusal = "A directory cannot be moved inside itself.";
+            return false;
+        }
+
+        refusal = string.Empty;
+        return true;
+    }
 
     /// <inheritdoc />
     public async ValueTask DisposeAsync()
@@ -1713,13 +2101,31 @@ internal sealed partial class TransfersViewModel : ObservableObject, IAsyncDispo
         return RunAsync($"Reading {path}…", () => ListRemoteAsync(path, cancellationToken));
     }
 
+    /// <remarks>
+    /// <para>
+    /// <b>The selection survives if the row it was on does.</b> Every listing replaces every row object, so
+    /// keeping the object would keep a selection pointing at something no longer in the list; it is re-found
+    /// by path instead. This matters because a listing is no longer only something somebody asked for — a
+    /// finished upload refreshes this pane on its own, and a refresh that cleared the selection would take
+    /// the row out from under whoever was about to press RENAME on it.
+    /// </para>
+    /// <para>
+    /// The path box is written back here rather than by each caller, so that every way of moving — a crumb,
+    /// UP, a pin, connecting, a rename that lands — leaves the box saying where the pane actually is.
+    /// </para>
+    /// </remarks>
     private async Task ListRemoteAsync(string path, CancellationToken cancellationToken)
     {
         var entries = await RequireSession().ListAsync(path, cancellationToken).ConfigureAwait(true);
+        var wasSelected = SelectedRemoteEntry?.FullPath;
 
         RemotePath = path;
+        RemotePathDraft = path;
         SelectedRemoteEntry = null;
 
+        // Whatever made it stale, this is a fresh read of the very directory that was stale.
+        remoteListingIsStale = false;
+
         RemoteEntries.Clear();
 
         foreach (var entry in entries)
@@ -1734,10 +2140,99 @@ internal sealed partial class TransfersViewModel : ObservableObject, IAsyncDispo
             RemoteTrail.Add(new CrumbViewModel(name, crumb));
         }
 
+        SelectedRemoteEntry = wasSelected is null
+            ? null
+            : RemoteEntries.FirstOrDefault(
+                row => string.Equals(row.FullPath, wasSelected, StringComparison.Ordinal));
 
         Status = string.Empty;
     }
 
+    /// <summary>
+    /// Re-reads the remote directory because something landed in it, if now is a moment to.
+    /// </summary>
+    /// <remarks>
+    /// <para>
+    /// <b>An upload that finished is a listing that is wrong.</b> The pane went on showing the directory as
+    /// it was before the file arrived, and the only way to see the file that had just been sent was to press
+    /// REFRESH — which is the application asking somebody to tell it about something it did itself.
+    /// </para>
+    /// <para>
+    /// <b>It waits rather than interrupting.</b> Three states are not the moment: another operation is
+    /// running, which would have two listings racing for the same collection; one of the three questions is
+    /// on screen, and pulling the listing out from under a question about a row is how the row somebody
+    /// answered about stops being the row that was acted on; or nothing is connected. In all three the
+    /// staleness is remembered and settled later — at the end of the operation, or when the question is
+    /// dismissed.
+    /// </para>
+    /// <para>
+    /// <b>It says nothing.</b> Nobody asked for this listing, so it neither announces itself nor reports a
+    /// failure: the status line at that moment is carrying the word about the transfer that just finished,
+    /// which is the news. A refresh that failed leaves the pane as it was and the staleness set, so the next
+    /// settling tries again.
+    /// </para>
+    /// </remarks>
+    internal async Task SettleRemoteListingAsync()
+    {
+        if (!remoteListingIsStale || !IsConnected || IsBusy || IsAskingAboutRemoteEntry
+            || RemotePath.Length == 0)
+        {
+            return;
+        }
+
+        var said = Status;
+
+        IsBusy = true;
+
+        try
+        {
+            await ListRemoteAsync(RemotePath, CancellationToken.None).ConfigureAwait(true);
+
+            Status = said;
+        }
+        catch (Exception exception) when (exception is not OutOfMemoryException)
+        {
+            remoteListingIsStale = true;
+        }
+        finally
+        {
+            IsBusy = false;
+        }
+    }
+
+    /// <summary>
+    /// Notices that a finished transfer changed a directory that is on screen.
+    /// </summary>
+    /// <remarks>
+    /// Both panes, because both go stale the same way and for the same reason — an upload lands on the host
+    /// and a download lands on this machine, and whichever pane is showing that directory is now showing it
+    /// as it was a moment ago. Only the directory actually on screen: a transfer into somewhere else changed
+    /// nothing anybody is looking at, and re-listing for it would be a round trip per completed transfer in
+    /// a queue that may be moving a hundred files elsewhere.
+    /// </remarks>
+    internal void NoteTransferLanded(TransferSnapshot transfer)
+    {
+        if (transfer.Direction is TransferDirection.Upload)
+        {
+            if (string.Equals(SftpPath.Parent(transfer.RemotePath), RemotePath, StringComparison.Ordinal))
+            {
+                remoteListingIsStale = true;
+
+                _ = SettleRemoteListingAsync();
+            }
+
+            return;
+        }
+
+        // The local pane is a filesystem call rather than a round trip, so there is nothing to defer: it is
+        // re-read where it stands. Compared case-insensitively because this end is Windows as often as not.
+        if (string.Equals(
+            Path.GetDirectoryName(transfer.LocalPath), LocalPath, StringComparison.OrdinalIgnoreCase))
+        {
+            NavigateLocal(LocalPath);
+        }
+    }
+
     /// <remarks>
     /// Synchronous, unlike its remote counterpart. A local directory listing is a filesystem call rather than
     /// a network round trip, and wrapping it in a task would put a state machine and a thread hop behind
@@ -1748,6 +2243,7 @@ internal sealed partial class TransfersViewModel : ObservableObject, IAsyncDispo
         try
         {
             var entries = LocalDirectory.List(path);
+            var wasSelected = SelectedLocalEntry?.FullPath;
 
             LocalPath = Path.GetFullPath(path);
             SelectedLocalEntry = null;
@@ -1761,6 +2257,13 @@ internal sealed partial class TransfersViewModel : ObservableObject, IAsyncDispo
 
             RebuildLocalTrail();
 
+            // Re-found by path rather than kept, for the reason ListRemoteAsync gives: a finished download
+            // re-reads this pane on its own, and a refresh that cleared the selection would take the row
+            // out from under whoever was about to send it somewhere.
+            SelectedLocalEntry = wasSelected is null
+                ? null
+                : LocalEntries.FirstOrDefault(
+                    row => string.Equals(row.FullPath, wasSelected, StringComparison.OrdinalIgnoreCase));
         }
         catch (Exception exception) when (exception is IOException or UnauthorizedAccessException)
         {
@@ -1877,10 +2380,19 @@ internal sealed partial class TransfersViewModel : ObservableObject, IAsyncDispo
         ConnectedPinnedPaths.Clear();
         OnPropertyChanged(nameof(HasConnectedPins));
         RemotePath = string.Empty;
+        RemotePathDraft = string.Empty;
         RemoteEntries.Clear();
         RemoteTrail.Clear();
         SelectedRemoteEntry = null;
 
+        // Both questions go with the session they were about, and the box either of them was filled in
+        // from with them. A form left open over a pane that is no longer connected to anything would
+        // commit against RequireSession's own refusal.
+        PendingRemoteDeletion = null;
+        PendingRemoteMove = null;
+        RemoteMoveTarget = string.Empty;
+        remoteListingIsStale = false;
+
         // Same ordering reason as the raise at the end of MarkHostConnected: both properties this reads are
         // already null above, so the raise belongs after them rather than in OnIsConnectedChanged. This also
         // covers OpenBucketAsync, which calls this method first and never itself turns HasLiveFileSession on.
@@ -1911,6 +2423,9 @@ internal sealed partial class TransfersViewModel : ObservableObject, IAsyncDispo
                 {
                     ReleaseStaged(e.Transfer.LocalPath);
                 }
+
+                // Whichever pane the bytes landed in is showing that directory as it was before they did.
+                NoteTransferLanded(e.Transfer);
             }
 
             if (Transfers.FirstOrDefault(row => row.Id == e.Transfer.Id) is { } existing)
@@ -1961,6 +2476,10 @@ internal sealed partial class TransfersViewModel : ObservableObject, IAsyncDispo
         {
             IsBusy = false;
         }
+
+        // The one place every command on this screen passes through on its way out, which makes it the one
+        // place a listing that went stale while it was running can safely be settled.
+        await SettleRemoteListingAsync().ConfigureAwait(true);
     }
 
     partial void OnSelectedHostChanged(HostRowViewModel? value) =>
@@ -2002,7 +2521,7 @@ internal sealed partial class TransfersViewModel : ObservableObject, IAsyncDispo
     {
         OnPropertyChanged(nameof(CanDownload));
         OnPropertyChanged(nameof(CanUpload));
-        OnPropertyChanged(nameof(CanDeleteRemote));
+        RaiseItemActionState();
 
         // Both ways, and the disconnecting half is the one worth stating: closing a session puts the pane
         // back to its invitation rather than to the form, so what the pane shows after a disconnect is the
@@ -2019,14 +2538,37 @@ internal sealed partial class TransfersViewModel : ObservableObject, IAsyncDispo
     partial void OnSelectedRemoteEntryChanged(RemoteEntryRowViewModel? value)
     {
         OnPropertyChanged(nameof(CanDownload));
+        OnPropertyChanged(nameof(SelectedRemoteName));
 
         PendingRemoteDeletion = null;
+        PendingRemoteMove = null;
     }
 
     partial void OnPendingRemoteDeletionChanged(RemoteDeletionRequest? value)
     {
         OnPropertyChanged(nameof(IsConfirmingRemoteDeletion));
+        RaiseItemActionState();
+    }
+
+    partial void OnPendingRemoteMoveChanged(RemoteMoveRequest? value)
+    {
+        OnPropertyChanged(nameof(IsMovingRemote));
+        RaiseItemActionState();
+    }
+
+    /// <summary>Raises the flags the three item buttons and their two forms are drawn from.</summary>
+    /// <remarks>
+    /// Together, because they are one fact — is there a question on screen, and is anything connected —
+    /// read five ways, and a caller that raised some of them would leave a button live beside a form that
+    /// says it is not.
+    /// </remarks>
+    private void RaiseItemActionState()
+    {
+        OnPropertyChanged(nameof(IsAskingAboutRemoteEntry));
+        OnPropertyChanged(nameof(ShowsRemoteItemActions));
         OnPropertyChanged(nameof(CanDeleteRemote));
+        OnPropertyChanged(nameof(CanRenameRemote));
+        OnPropertyChanged(nameof(CanMoveRemote));
     }
 
     partial void OnSelectedLocalEntryChanged(LocalEntryRowViewModel? value) =>