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.
Build 920: Crash after CTRL+Drag (copy) of file from left to right window
Re: Build 920: Crash after CTRL+Drag (copy) of file from left to right window
Unfortunately, I cannot reproduce it.
It works fine here.
It works fine here.
Re: Build 920: Crash after CTRL+Drag (copy) of file from left to right window
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.
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.
Who is online
Users browsing this forum: Google [Bot] and 11 guests