Recent Posts

Pages: [1] 2 3 4 5 ... 10
1
I continue to try to tweak settings in MC in an attempt to make it a program that I love instead of just like.  Yesterday I was playing in Quick Look'n'Feel Settings.  I now don't see any way to tell which option is currently active and am wondering if a change there could have caused the significant slowness I now routinely experience when opening a folder.  I reviewed all other settings in Core and Explorer Panel so I may have changed something there that has resulted in this slowdown.  Also, sometimes on MC startup I will briefly see a message in an explorer pane that says something about a filesystem scan.  I would appreciate advice on how I can determine which Quick Look'n'Feel Setting is active, and any option that could be causing the slowness in displaying folder content.  FWIW, "Cache folder size for better performance" is enabled but I don't know if that is dependent on "Everything" which is not enabled.
2
MC is using newest version of LibSSH2 ( v1.11.1 )

Last time I check it was an issue with LibSSH2 not supporting it on Windows 7 since it require method that only exists on Windows 10. Problem is that they are not checking if that method exists dynamically. so it is required at build time.  so then MC will not work on Win7. (Still around 3-4% of users is using MC on Win7, But more and more issues popup to be able to support Win7.  )
I been thinking about building two version of the FS-SFTP extension, (Win7 version and one normal for newer Windows ) But that require a lot of handling and thing around that need to be changed. And I have not had time to investigate all that
3
Support and Feedback / Re: SFTP Connection fails
« Last post by Mathias (Author) on Today at 09:40:12 »
Actually it is libssh2 and Windows issues.. 
4
Support and Feedback / Re: SFTP Connection fails
« Last post by moxuanyuan on Today at 08:19:28 »
I ran into the exact same issue. Here is the reason and how to fix it.

The Root Cause
Multi Commander's built-in SFTP module uses an outdated libssh2 library. It only supports legacy algorithms (like ssh-rsa with SHA-1, diffie-hellman-group14-sha1). Modern Linux servers (Debian 12, Ubuntu 22.04+) disable these by default for security, causing the handshake to fail with (null) errors.

Solution 1: Modify Server Config (Workaround)
If you can manage the server, you can force it to allow legacy algorithms:

Edit SSH config: sudo nano /etc/ssh/sshd_config

Add these lines to the very bottom:

KexAlgorithms +diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha256
Ciphers +aes128-cbc,aes256-cbc,aes128-ctr,aes256-ctr
HostKeyAlgorithms +ssh-rsa
PubkeyAcceptedKeyTypes +ssh-rsa

Restart SSH: sudo systemctl restart ssh

In Multi Commander, clear all keyfile paths and use pure password authentication (it cannot parse modern Ed25519 keys).

Solution 2: Mount as Local Drive (Recommended)
Instead of degrading server security, use tools like RaiDrive or Rclone to mount your SFTP server as a local Windows drive letter (e.g., Z:). You can then manage files in Multi Commander just like a local drive with full speed and modern security.

Hope the developer can update the underlying library soon!
5
Hi Multi Commander Team,

First of all, thank you for developing such an amazing and efficient dual-panel file manager. It has been a core part of my daily workflow.

I would like to request an upgrade for the built-in SFTP/SCP plugin. Currently, when trying to connect to modern Linux servers (such as Debian 12, Ubuntu 22.04+, or modern LXC containers), the connection consistently fails during the handshake phase, resulting in the following log errors:
Key exchange method : (null)
Authentication handshake failed : No method negotiated

The Root Cause:
Modern OpenSSH servers have completely deprecated legacy and insecure algorithms by default (such as ssh-rsa with SHA-1, diffie-hellman-group14-sha1, and CBC ciphers). They now require modern cryptography like Ed25519, rsa-sha2-256, or aes128/256-gcm.

Unfortunately, Multi Commander's internal SFTP library (seemingly based on an older version of libssh2) doesn't support these modern standards yet. To make it work, users are forced to manually downgrade their server's SSH security configurations, which poses significant security risks even in a local HomeLab environment.

Suggested Improvement:
Could you please consider updating the underlying SSH/SFTP library (e.g., upgrading to the latest version of libssh2 or migrating to a more modern SSH backend) in an upcoming release? Supporting Ed25519 keys and modern KEX/Cipher algorithms would bring Multi Commander's SFTP plugin back to modern standards.

Thank you for your time and continuous effort in improving this great tool!

Best regards
6
Gemini 3.5 Flash AI generated::
The intermittent "works on the second try" bug you are experiencing is a classic symptom of how Windows handles process creation and Shell communication, specifically when using `cmd.exe` as an unnecessary middleman.

Here is the refactored, robust version of your MultiScript. Below it is a breakdown of exactly why your original script was misbehaving.

### The Robust MultiScript (Replace `"C:\\Path\\To\\syspin.exe"` with the actual full path to your `syspin.exe`. Do the same and modify the code to extend support across all remaining operational modes):
Code: [Select]
```MultiScript
@var $filePath = GetSourceFocusPath();
@var $syspin = "C:\\Path\\To\\syspin.exe"; // Ensure double backslashes

// 1. Sanity Check: Prevent execution if no file is focused
if ( $filePath == "" ) {
    return;
}

// 2. Format arguments cleanly without the cmd.exe syntax
@var $args = "\"" + $filePath + "\" 5386";

// 3. Direct Execution: Bypass cmd.exe completely
MC.Run CMD="{$syspin}" ARG="{$args}";
```

Here are the rest of the codes:
+--------------------------------------------------------------+
| Action                     | Code   | Description                 |
+----------------------------|--------|------------------------------+
| Pin to taskbar             | 5386   | Pin the file to taskbar     |
| Unpin from taskbar         | 5387   | Remove from taskbar        |
| Pin to Start               | 51201  | Pin to Start menu          |
| Unpin from Start           | 51394  | Remove from Start menu     |
+--------------------------------------------------------------+

### What was causing the bug? (Under the Hood)

Your original script was doing this:
`MC.Run CMD="cmd.exe" ARG="/C \"\"C:\syspin.exe\" \"C:\file.txt\" 5386\"";`

There are two low-level mechanisms at play here that cause this to fail intermittently, requiring a second attempt.

#### 1. The `cmd.exe` Quoting Trap

When you invoke `cmd.exe` with the `/C` (terminate after execution) flag, you pass the command string into a notoriously complex parser. If the first and last characters of the argument string are quote marks, `cmd.exe` attempts to apply a heuristic to decide whether to strip them.

Depending on whether `$syspin` or `$filePath` contained spaces, `cmd.exe` might strip the outer quotes but fail to properly tokenize the inner ones. This often results in a malformed path being passed to the system, causing `cmd.exe` to quietly abort the operation without an error message. On the second click, the environment state or memory caching might shift just enough for the command to parse, or Explorer "catches up."

#### 2. Win32 Shell COM Interruption (The Real Culprit)

SysPin works by tapping into the Windows Shell API. It does not literally edit your taskbar registry keys; instead, it programmatically invokes an `IShellDispatch` Context Menu Verb (specifically the verb internally mapped to the ID `5386`).

This relies on COM (Component Object Model) Inter-Process Communication (IPC) to send a message to `explorer.exe`.

When you wrap SysPin inside `cmd.exe /C`, you are creating a transient parent process.

1. MultiCommander spawns `cmd.exe`.
2. `cmd.exe` spawns `syspin.exe`.
3. `syspin.exe` sends the COM request to `explorer.exe` to pin the item.
4. `cmd.exe` sees `syspin.exe` executing and often immediately begins its own tear-down process because of the `/C` flag.

If the console subsystem tears down the process tree *before* `explorer.exe` has fully finished handling the COM message across process boundaries, the taskbar pin operation is abruptly dropped. The first attempt "wakes up" the shell verb handler in Explorer, and the second attempt succeeds because the handler is now cached and responds fast enough to beat the `cmd.exe` shutdown window.

### The Fix

By changing `MC.Run` to target `syspin.exe` directly, you bypass the command interpreter entirely. MultiCommander uses standard Win32 `CreateProcess` to launch SysPin in its own stable, independent process space. SysPin can now cleanly send its COM message to the Windows Shell, wait for the acknowledgment, and exit gracefully without an artificial `cmd.exe` wrapper pulling the rug out from under it.
7
This is a follow-up. The previous scripts had compatibility issues with older Win 95+ OS's-based Screensavers etc. (they wouldn't detect the Wallpaper like in the BLOCKS/ Windows 98.SCR screensaver)

Legacy Windows 98 Screensaver Compatibility Fix via PowerShell
The issue stems from two primary compatibility gaps between modern Windows 10 and legacy Win32/16 architecture:

  • Image Format Limitation: Legacy screensavers (e.g., Windows 98.SCR) lack JPEG/PNG decoding capabilities and rely solely on uncompressed BMP files for textures.
  • Registry Synchronization: Modern Windows 10 manages wallpaper transcoding internally, often failing to update legacy registry keys (HKCU:\Control Panel\Desktop\Wallpaper) with raw image paths, causing detection failures.

Solution Overview:
  • On-the-fly BMP Conversion: The script leverages .NET's System.Drawing to transcode any user-selected image (JPG, PNG, WebP) into a 24-bit BMP, ensuring compatibility.
  • Reliable Storage Path: Saves the BMP to a predictable, short path (e.g., $env:USERPROFILE\classic_wallpaper.bmp) to facilitate detection by legacy screensavers.
  • Registry & API Updates: Manually updates the Wallpaper registry key with the BMP path and invokes SystemParametersInfo API with SPI_SETDESKWALLPAPER to immediately apply, ensuring the screensaver detects the correct wallpaper image.

You need five of these scripts for each of the modes (replace the code lines of each according to the following):
+--------------------------------------------------------+
|                Style Reference Map                     |
+------------------------------+-------------------------+
| Style                        | Registry Settings      |
+------------------------------+-------------------------+
| Stretch                      | WallpaperStyle='2'      |
|                              | TileWallpaper='0'       |
+------------------------------+-------------------------+
| Fit                          | WallpaperStyle='6'      |
|                              | TileWallpaper='0'       |
+------------------------------+-------------------------+
| Fill                         | WallpaperStyle='10'     |
|                              | TileWallpaper='0'       |
+------------------------------+-------------------------+
| Center                       | WallpaperStyle='0'      |
|                              | TileWallpaper='0'       |
+------------------------------+-------------------------+
| Tile                         | WallpaperStyle='0'      |
|                              | TileWallpaper='1'       |
+------------------------------+-------------------------+
| Span                         | WallpaperStyle='22'     |
|                              | TileWallpaper='0'       |
+------------------------------+-------------------------+

1. Here's the full script for 'Stretched', change the two values and repeat for the rest of the scripts modes (Gemini 3.5 Flash AI Generated):
Code: [Select]
```SetWallpaperMCStretch.ps1
param([string]$ImagePath)

# Validate file exists
if (-not (Test-Path $ImagePath)) {
    Write-Error "File not found: $ImagePath"
    exit 1
}

# Load .NET Assembly for Image Processing
Add-Type -AssemblyName System.Drawing

# Define a clean, static path for the legacy BMP file
# Legacy screensavers handle paths without spaces much better
$BmpPath = "$env:USERPROFILE\classic_wallpaper.bmp"

# Convert the source image to a 24-bit BMP to satisfy the Win98 screensaver engine
try {
    $SrcImage = [System.Drawing.Image]::FromFile($ImagePath)
   
    # If a previous wallpaper BMP exists, delete it first to release file locks
    if (Test-Path $BmpPath) {
        Remove-Item $BmpPath -Force -ErrorAction SilentlyContinue
    }
   
    # Save as BMP format
    $SrcImage.Save($BmpPath, [System.Drawing.Imaging.ImageFormat]::Bmp)
    $SrcImage.Dispose()
}
catch {
    Write-Error "Failed to process and convert image: $_"
    exit 1
}

# Set style: Stretch (Style '2', Tile '0')
Set-ItemProperty -Path 'HKCU:\Control Panel\Desktop' -Name WallpaperStyle -Value '2'
Set-ItemProperty -Path 'HKCU:\Control Panel\Desktop' -Name TileWallpaper -Value '0'

# FORCE legacy wallpaper path update in the registry for the screensaver
Set-ItemProperty -Path 'HKCU:\Control Panel\Desktop' -Name Wallpaper -Value $BmpPath

# Apply wallpaper via Win32 API
Add-Type -TypeDefinition @"
using System;
using System.Runtime.InteropServices;
public class Wallpaper {
    [DllImport("user32.dll", CharSet = CharSet.Auto)]
    public static extern int SystemParametersInfo(int uAction, int uParam, string lpvParam, int fuWinIni);
}
"@ -ErrorAction SilentlyContinue

# SPI_SETDESKWALLPAPER = 0x0014 (20)
# SPIF_UPDATEINIFILE | SPIF_SENDCHANGE = 3
[Wallpaper]::SystemParametersInfo(20, 0, $BmpPath, 3)
```


2. Plus interface it in MC 'User-Defined Command' script like this (replace the FilePath in the script with your local path (ensure directory separators are escaped with double backslashes \\).):
Code: [Select]
```MultiScript
@var $imgPath = GetSourceFocusPath();
@var $arguments = "-ExecutionPolicy Bypass -File \"C:\\Path\\To\\SetWallpaperMCStretch.ps1\" -ImagePath \"" + $imgPath + "\"";
MC.Run CMD="cmd.exe /c powershell.exe" ARG="{$arguments}";
```

Notes:
Tested on MC 16.0 running on Windows 10.
To add to the context menu: navigate to Config > "Custom Context Menu" and add the script.

Technical Highlights:
  • Uses PowerShell + .NET for image transcoding.
  • Sets appropriate registry values (WallpaperStyle and TileWallpaper) for correct display behavior.
  • Invokes Win32 API call for immediate wallpaper refresh.
  • Ensures backward compatibility for Win95/98-style screensavers expecting BMP textures and registry cues.
8
Beta Releases / Re: v16.0 Beta
« Last post by Mathias (Author) on May 22, 2026, 17:30:06 »
Quote

I can't reproduce that.   The column thing might be fixed with the other column issues that was fixed.. but the miscalculation of items I can't reproduce.

Thanks for fixing the column thing ;)
I am still having the queue weirdness but I suspect that the fact I'm using a custom commmand & the NODIALOG option may be related as F6 has behaved better.
See attached CC dialog entry.
So what is happening ? items not added to queue at all ?  What is the situation. lots of large /small files.. and you add to existing when there is allready a file operation in process... so it is not added to queue ? or something else.. ?
9
Beta Releases / Re: v16.0 Beta
« Last post by Ulfhednar on May 22, 2026, 15:18:53 »
Quote

I can't reproduce that.   The column thing might be fixed with the other column issues that was fixed.. but the miscalculation of items I can't reproduce.

Thanks for fixing the column thing ;)
I am still having the queue weirdness but I suspect that the fact I'm using a custom commmand & the NODIALOG option may be related as F6 has behaved better.
See attached CC dialog entry.
10
Support and Feedback / Re: Lost menu bar
« Last post by Mathias (Author) on May 21, 2026, 11:05:39 »
Ctrl+M
Pages: [1] 2 3 4 5 ... 10