Perf: Use smb2::FileWriter::abort() on cancelled uploads

`SmbVolume::import_single_file_with_progress` and `write_from_stream` called `writer.finish()` on cancel, which forces a server-side FLUSH (fsync) on a file we're about to delete anyway. Swap to the new `writer.abort()` from smb2 `1d91384`, which drains in-flight WRITE responses to keep credits/message IDs in sync but skips the fsync and does a best-effort CLOSE. Saves ~100 ms to ~1 s on slow NAS cancels.

Also bumped Cargo.lock to pick up smb2 `1d91384c` (the `abort()` release).

Author: vdavid

Cargo.lock

@@ -374,11 +374,12 @@ impl SmbVolume {
             bytes_done += n as u64;
 
             if on_progress(bytes_done, total_size) == std::ops::ControlFlow::Break(()) {
-                // Finalize the writer to drain in-flight WRITE responses and
-                // close the handle — if we just drop it, stale responses
-                // poison the session for the next op. Best-effort delete of
-                // the partial file afterwards.
-                let _ = writer.finish().await;
+                // Abort drains in-flight WRITE responses and closes the handle
+                // without the server-side fsync that `finish()` would force
+                // (we're about to delete the partial file anyway). Dropping
+                // the writer directly would leave stale responses on the
+                // connection and poison the next op.
+                let _ = writer.abort().await;
                 let _ = client.delete_file(tree, smb_path).await;
                 return Err(VolumeError::Cancelled("Operation cancelled by user".to_string()));
             }
@@ -1385,11 +1386,12 @@ impl Volume for SmbVolume {
                 bytes_read += chunk.len() as u64;
 
                 if on_progress(bytes_read, size) == std::ops::ControlFlow::Break(()) {
-                    // Finalize the writer to drain in-flight WRITE responses
-                    // and close the handle — dropping it directly would leave
-                    // stale responses on the connection, poisoning the next op.
-                    // Best-effort delete of the partial file afterwards.
-                    let _ = writer.finish().await;
+                    // Abort drains in-flight WRITE responses and closes the
+                    // handle without the server-side fsync that `finish()`
+                    // would force (we're about to delete the partial file
+                    // anyway). Dropping directly would leave stale responses
+                    // on the connection and poison the next op.
+                    let _ = writer.abort().await;
                     let _ = client.delete_file(tree, &smb_path).await;
                     return Err(VolumeError::Cancelled("Operation cancelled by user".to_string()));
                 }
@@ -2626,7 +2628,7 @@ mod tests {
     async fn smb_integration_import_from_local_cancel_mid_write() {
         // Cancel partway through a multi-chunk import via progress-break.
         // Verifies Cancelled is returned and that the SMB session is still
-        // usable for subsequent ops (writer.finish() drains in-flight WRITE
+        // usable for subsequent ops (writer.abort() drains in-flight WRITE
         // responses cleanly on cancel, best-effort-deletes the partial file).
         let vol = make_docker_volume().await;
         let dir = test_dir_name();

apps/desktop/src-tauri/src/file_system/volume/smb.rs

@@ -126,9 +126,8 @@ When directory has parent entry shown at index 0, frontend indices are offset by
 - **Scan preview reuse**: TransferDialog starts a scan preview on mount. If the user confirms before the scan finishes,
   the scan keeps running (TransferDialog sets `confirmed = true` and skips cancellation in `onDestroy`).
   TransferProgressDialog picks up listening to the same scan events via `scanInProgress` prop. `waitForScanThenStart`
-  subscribes to the scan events first, then awaits `checkScanPreviewStatus()`. Both the `scan-preview-complete`
-  listener AND the status check can signal "ready to start" — especially for fast scans that complete during the
-  status-check `await`. Both paths converge on a local `kickOff()` helper guarded by a `started` flag, so
-  `startOperation()` dispatches exactly once. The scan-error and scan-cancelled listeners also flip `started = true`
-  as a terminal signal, so a late `scan-preview-complete` event can't dispatch an operation after we've errored or
-  cancelled.
+  subscribes to the scan events first, then awaits `checkScanPreviewStatus()`. Both the `scan-preview-complete` listener
+  AND the status check can signal "ready to start" — especially for fast scans that complete during the status-check
+  `await`. Both paths converge on a local `kickOff()` helper guarded by a `started` flag, so `startOperation()`
+  dispatches exactly once. The scan-error and scan-cancelled listeners also flip `started = true` as a terminal signal,
+  so a late `scan-preview-complete` event can't dispatch an operation after we've errored or cancelled.