Build 920: Crash after CTRL+Drag (copy) of file from left to right window

Bugs and issues - current donor version.
Post Reply
Message
Author
ThomAC
Posts: 5
Joined: 20.09.2018, 11:58

Build 920: Crash after CTRL+Drag (copy) of file from left to right window

#1 Post by ThomAC » 22.01.2025, 16:03

FreeCommander XE 2025 Build 920 64-bit donor, Windows 11 Version 24H2 (Build 26100.2894)

"CTRL+Dragging" of file from left to right window crashes FreeCommander if target path is long. Unfortunately it is not a fix number of characters but in the range of >130 ... >140 characters.

Detailled Explanation:
To avoid Windows (and FreeCommander) moving files without asking when they are dragged into a folder on the same drive, I have gotten into the habit of ALWAYS holding down the CTRL key when dragging files.

When I release the key in the target window of Freecommander, the Popup menu appears in FreeCommander where I can select whether I want to move or copy the file.
(I have enabled the Popup menu in Freecommander settings.)

If I select “Copy” and the file already exists, I will be asked, as expected, whether the file should be overwritten.

If I answer yes, FreeCommander crashes (is closed) during the copying process if the path is too long. If I shorten the path, it will eventually work without crashing.

The crash only happens if an existing file is overwritten. If the file to be copied does not yet exist in the target folder, the crash never occurs.

Marek
Author
Author
Posts: 4229
Joined: 10.04.2006, 09:48
Location: Germany
Contact:

Re: Build 920: Crash after CTRL+Drag (copy) of file from left to right window

#2 Post by Marek » 24.01.2025, 22:31

Unfortunately, I cannot reproduce it.
It works fine here.

ThomAC
Posts: 5
Joined: 20.09.2018, 11:58

Re: Build 920: Crash after CTRL+Drag (copy) of file from left to right window

#3 Post by ThomAC » 26.01.2025, 12:48

Thank you very much. That is a great pity.

I was able to repeat the problem with artificially created paths, but did not find a clear limit directly related to the number of subfolders or the number of characters in the path names. Only above a fuzzy limit of about 130 characters in the entire target path did the crash occur during the step when the existing target file was overwritten.

(Just as an addition: In the settings I have set Windows as the method for deleting, but FC method for copying and moving, because this allows me to keep the time of the files and folders).

I'll keep an eye on it and get back to you if I get another clue.

Post Reply

Who is online

Users browsing this forum: Semrush [Bot] and 4 guests