Messages

1

Support and Feedback / Re: Drag and drop images from Firefox always converts them to BMP

« on: December 04, 2024, 19:49:26 »

ClipSpy shows the following clipboard formats:

• CF_TEXT, with for example the content "https://multicommander.com/Images/FrontPageFeatures/networking-features.png"
• CF_UNICODETEXT, with the same content as CF_TEXT, but in UTF16
• CF_DIB, with some binary bitmap data
• CF_DIBV5, with more binary bitmap data
• CF_HDROP, with some binary data containing the text "D:\temp\Peter\h3ihzctz.bmp"

So the clipboard contains URLs that point to the original image, binary bitmap data of the image and a path to a temporary *.bmp file for the image.

I guess one can not blame MC to take the available bitmap data instead of getting the original files from the URL (as Windows Explorer seems to do).
Therefore I withdraw my complaint. Thanks for pointing me to the ClipSpy app though.

Fun fact: Dragging and dropping an image from Edge to MC works as I would have expected. Why? Because Edge only delivers CF_TEXT and CF_UNICODETEXT in the clipboard and no bitmap data. Like with Firefox, both formats contain the image URL.

About making MC Open Source: I understand your concerns and of course respect your decision.

2

Support and Feedback / Drag and drop images from Firefox always converts them to BMP

« on: December 04, 2024, 17:11:41 »

When images are dragged from a web page in Firefox and dropped into a folder in Multi Commander, they are always converted to BMP They should keep their original format, like JPG or PNG.

When dropping the images into a folder in Windows Explorer, they do keep their original format without any conversion. Therefore the necessary information must exist.
Copying an image in Firefox and pasting it into an MC folder is also correctly handled. It's only with drag and drop, that the unwanted conversion occurs.

Mathias, did you ever consider making the whole project Open Source, so that others could help fixing all these little nuisances?

3

Support and Feedback / Drag and drop: "Move to" Window can not be turned off independently

« on: November 22, 2024, 15:00:04 »

When moving or copying files or folders by drag and drop, a dialog pops up where you can adjust some settings before starting the operation.

The appearance of that dialog can be controlled in <Core Settings> / <Filesystem> / <Drag and Drop file operations>.
The checkbox <Move - Show "Move To" window before starting> has no effect however.
The checkbox <Copy - Show "Copy To" window before starting> controls the appearance of the dialog for both operations - "copy" and "move". It's not possible to control it for move only.

It would be cool by the way, if one could turn off these dialogs in general, but be able to let them appear on occasion, maybe by pressing "Shift" or "Alt" while dragging the mouse and before dropping the items. Most of the times I'm satisfied with the way the file system operations work and then it's a bit annoying when I have to confirm them. But sometimes tweaks are necessary.

4

Support and Feedback / Re: File symlinks not copied

« on: October 07, 2024, 20:07:17 »

Thanks for confirming the assumption.

It would be great, if you removed that check.
Currently it's not possible to copy a directory to a different volume and restore it later to the original location, without possibly losing some symlinks.

5

Support and Feedback / Re: File symlinks not copied

« on: October 07, 2024, 15:27:46 »

Thanks for the reply.

If I do it exactly as you described, I get the same result as you (I love determinism ).

However my use case is a bit different:

I have:
C:\MyFolder\MyFile.txt
C:\MyFolder\SubFolder\MyFile.txt ( Symlink -> "..\MyFile.txt" )

I don't know whether the symlink with relative path can be created with MC. I created it via the command line:

mklink C:\MyFolder\SubFolder\MyFile.txt ..\MyFile.txt

When I drag&drop C:\MyFolder to D:\, the directory "D:\MyFolder\SubFolder" exists, but is empty, i.e. the symlink is not copied.

Experimenting a bit I found that when the symlink contains an absolute path to the target file (-> "C:\MyFolder\MyFile.txt"), it is correctly copied.
Having a symlink with an absolute path to a file that does not exist, has the same effect as with the relative path: the symlink is not copied.

There seems to be some check, whether the link target exists. Maybe in case of the relative path, the symlink is copied before the file and therefore the link target does not (yet) exist.

In my opinion no checks concerning the link target should be made. The symlink should always be copied and it should contain exactly the same target as the original, no matter whether it can be resolved to an existing file at the new location or not.

6

Support and Feedback / File symlinks not copied

« on: September 30, 2024, 15:37:38 »

When copying file symlinks or directories that contain file symlinks, the symlinks are not copied.

In core settings / tab "Filesystem" / section "Junctions and Symbolic links", the option "when copying or moving" is set to "Copy or move the link itself".

• When copying with drag&drop, the file symlinks are not copied at all.
• When copying with copy&paste, the file to which the symlink points is copied, not the symlink itself.

Moving file symlinks works as expected with drag&drop and with copy&paste. The symlinks themselves are moved in both cases and not the files they points to.

With copy it should be the same way.

7

Support and Feedback / Ctrl-C and Ctrl-V not working in Favorites dialog

« on: May 26, 2024, 14:42:40 »

The documentation for favorites says:

Ctrl+C and Ctrl+V can be used to copy and paste Favorites. They can be used to copy a Favorite from one section and paste it into another.

But the keyboard shortcuts Ctrl+C and Ctrl+V have no effect in the Favorites dialog, neither in the current version (v13.5) nor in older versions (tried with v11.3 from 2021).

It's just a minor problem and fortunately there is a workaround:
Copying and pasting in the Favorites dialog can be done via the context menu.

8

Support and Feedback / Re: "Show link target in name column" only affects symlinks to directories

« on: May 24, 2024, 12:17:05 »

Thanks a lot.
It's very cool software by the way.

9

Support and Feedback / Re: "Show link target in name column" only affects symlinks to directories

« on: May 23, 2024, 21:23:58 »

That's really odd.

I tried it on 2 PCs, one with Windows 7, the other with Windows 10.
I tried it with the installer and the portable version.
I even tried earlier versions, back to the oldest available on the download page (v11.3).
The only changes in the configuration I made was unchecking "Show link target in name column".

The results were frustratingly consistent:
Toggling the option always made targets appear or disappear for symlinks to directories. But it had no effect on symlinks to files. For them the target was always displayed.

It's not as if the universe would implode, if that mystery couldn't be solved.
But it would be very convenient, if symlinks were a bit less obtrusive.

So, though I know that this question is slightly impertinent : Did it really really ever work as intended with file symlinks?

10

Support and Feedback / "Show link target in name column" only affects symlinks to directories

« on: May 23, 2024, 19:25:57 »

Hello!

For symlinks I would like the name column to contain only their name, but not the target that they point to.

The option "Show link target in name column" seems to be the right place to control this, but it affects only symlinks to directories. For them the link target disappears when the option is unchecked in the settings dialog.
For symlinks to files however, the link target is always displayed next to the name, no matter whether the option is checked or not.

Is that by design or am I doing something wrong?
I'm currently using the version 13.5.

Thanks.