Messages

1

Support and Feedback / [BUG REPORT] MC 10.2.0.2745 GUI SIZE ERROR

« on: January 28, 2021, 09:57:41 »

What to do: click multiple times "Show hidden and system files and folders" at the main windows
Expected result: no GUI change except panel contents
Real Result: panel with drop-down list of common disks and destinations, free space and panel management icons shrinks vertically  pixel by pixel every time you click until it reaches text font height.
MC: ver 10.2.0.2745 Portable

Possible cause: Rounding error of internal calculations?

2

Support and Feedback / Re: [BUG REPORT]MC10.1.0.2743:Search ASCII within OEM866 text file works wrong

« on: January 23, 2021, 08:32:27 »

Since most of the binary files do not have text-like extensions (*.txt, *.log etc.),  and MC has filters (with text file exteinsions filled in)... I'm just saying Of course, it's for user to decide wether filter be used or not. And which one.

3

Support and Feedback / Re: [BUG REPORT]MC10.1.0.2743:Search ASCII within OEM866 text file works wrong

« on: December 20, 2020, 13:29:37 »

Well. Not really a solution, but worth mentioning. Setting the checkbox "Search in binary files" forces MC to find the text we need, but the checkbox clears itself after the search is done. And I presume, unicode text will not be found in detected as false-binary text files, so not a viable solution. But proves the point the option to disable selectively some detectors including binary could be useful.

4

Support and Feedback / Re: [BUG REPORT]MC10.1.0.2743:Search ASCII within OEM866 text file works wrong

« on: December 19, 2020, 12:40:38 »

Here comes the log. If the binary is format #4 (the last in the list), it is the case then.

Code: [Select]

2020-12-19 14:39:33.626 [8452] Starting
2020-12-19 14:39:33.626 [Find Filter] Search Location #0 : D:\TEMP\_txt\
2020-12-19 14:39:33.626 [Find Filter] Rule #0 , 'File content' Contains (0x10) 'CanNotFindThis'
2020-12-19 14:39:33.627 [8452] Searching in folder : D:\TEMP\_txt
2020-12-19 14:39:33.627 [8452] Finished

2020-12-19 14:39:33.627 File Search - Content Search - File "D:\TEMP\_txt\LastLineWillNotBeFound.txt" detected as content format 4
The file is applied, the search text was "CanNotFindThis" (logs say the same). Settings screenshot is also applied.

5

Support and Feedback / Re: [BUG REPORT]MC10.1.0.2743:Search ASCII within OEM866 text file works wrong

« on: December 19, 2020, 11:29:35 »

I have a simmingly interesting idea for a (temporal?) workaround without drastical refactoring. What do you think of the 3-rd search mode? There are two of them: Single encoding, automatically detect all the encodings. Temporal workaroud could be the third mode - some interface for advanced users, that allows to disable/enable internal logic switch cases with checkboxes, i.e. :

√ UNICODE
   √ UTF-8
      √ BOM
      × NO-BOM
   × UTF-16
      × BOM
      × NO-BOM
   × UCS-2 BE
      × BOM
      × NO-BOM
   × UCS-2 LE
      × BOM
      × NO-BOM
√ ASCII
× BINARY

Now we have less thigs to choose from and less false-positives. But all the responsibility lays on the sholders of the user, so there has to be some clear statement on it for non-advanced ones not to flood the forum with claims after misconfiguration.

6

Support and Feedback / Re: [BUG REPORT]MC10.1.0.2743:Search ASCII within OEM866 text file works wrong

« on: December 10, 2020, 21:40:56 »

There is not only a magic number of 3+ bytes in range 0x80..0xff in line as a trigger. Even 3 national characters separated with 0x0d 0x0a (CR+LF) at the line end or with spaces each will thrigger the same error.

Let's use any national codes, 0xef or 0xff for example. The following byte (in hex) sequences anywhere in the file will stop further search:

HEX: ef 0d 0a ef 0d 0a ef 0d 0a ...

OR

HEX: ef ef ef 0a 0d ...

OR

HEX: ff 20 20 20 20 ff 20 20 20 ff 20 20 ... (ASCII text encoded starting from here with bytes 0x00..0x7f will not be found)

All the sequences trigger wrong encoding detection. BUT!
HEX: ff 20 20 20 20 ff 20 20 20 ff 20 20 20 ... (ASCII text starting from here will be found correctly)

It's hard to blame Unicode detection algorythm, but looks like it may be the case.
I wonder how one can detect UTF without BOM markers and not to mistaken it to some usual 8-bit encoding. Unicode is more repetetive in structure due to the same amount of bytes per character for the whole file. So, when there is no unicode "rythm" in the file, it can be a hint to treat it as 8-bit ascii-based encoding (CP-..., OEM..., UTF-8...)?

7

Support and Feedback / [BUG REPORT]MC10.1.0.2743:Search ASCII within OEM866 text file works wrong

« on: December 10, 2020, 11:54:57 »

Hello Mathias,

I've isolated a bug. While file search process is parsing OEM 866 encoded text files, with lines of pure latin (ASCII) and pure Cyrillic characters, search stops on the second line of Cyrillic characters and does not proceed further.

When just one last character of the second Cyrillic line is removed, search work correctly - the ASCII text at the end of the file is found!

Force search in ASCII encoding solves the problem (but some of my text files are Unicode, so i really need Auto mode).

Thanks for great software and your hard work,
Best regards.

8

Feature Requests and Suggestions / Overwrite dialogue needs more options

« on: February 05, 2020, 08:36:14 »

Hello, Mathias,

Would you be so kind to consider adding some more options to the "Overwrite the existing file in the target location" dialogue window?

"For all conflicts / Overwrite all if ..." would benefit from:

• More >>  Keep both if source is Newer OR Larger
  (it is needed to avoid useless duplicates current "keep both" options create)
• More >>  Overwrite all files if source is Newer OR Larger
  (it is needed when file is updated but size did not change)

Thanks in advance,
best regards.

9

Support and Feedback / Re: v 9.0 (build 2532)BUG: non-closable copy dialog

« on: January 20, 2020, 10:28:28 »

Sorry for the late reply. The latest MC versions so far do not reproduce the bug yet. I'll keep track of it just for the case.
In case e-mail reporting does not work, I'll post logs here in the future.

10

Support and Feedback / Clipboard gets RES#: instead of real Files/Folders Paths MC (x64) v9.6 (b2580)

« on: January 20, 2020, 10:10:24 »

Hello there, Mathias,

Long time no see. So, there is yet another unwanted feature. When using "Tools\To Clipboard" section, one might get the tab (pane) name instead of the paths that were found by search (Alt+F7) function.

File -> Find Files... -> Tools -> To Clipboard -> Files/Folder Paths

I presume, the reason is that the search result is treated as virtual folder (list) internally and there is no logic capable of extracting the real path for each file out of the data structure used.
Hope is would not bother you too much to solve the issue.
Thanks for your support through the years,
Best regards.
Simon.

11

Support and Feedback / Re: v 9.0 (build 2532)BUG: non-closable copy dialog

« on: September 10, 2019, 07:54:54 »

Animated screenshot attached.

12

Support and Feedback / v 9.0 (build 2532)BUG: non-closable copy dialog

« on: August 05, 2019, 08:07:55 »

Hello there. Mathias,

Another small bug report. Just now the MC x64 v9.0 (build 2532) Portable has shown some bug:

1. Started copying a list of files and folders to neighbouring directory, not included in the list
2. Copy process asked whether i like to replace files, I chose to replace with larger ones only.
3. Copy finished OK, but dialog window still in the state of copying with Interrupt button
4. Closing the window causes warning dialog "Do you want to interrupt the copy process", ignoring the fact there no files to copy left.
5. Dialog does NOT close even with close button, stop/interrupt button or Alt+F4
6. The bug is rare and not easily reproduceable.

Applied logs to mail via standard report dialog in the application.

Thanks a lot for your hard work, hope it was useful for you. Best regards,
Simon

13

Support and Feedback / Some key combination work only in Latin-letters based keyboard layouts

« on: April 13, 2019, 18:59:13 »

Hello, Mathias,

Could not get to you via e-mail as usual, so decided to post here.

There is a slight problem with hotkeys processing. Strange enough, but even non-literal combinations (i.e. ALT + SHIFT + ENTER to calculate folder size) do not work with non-latinbased keyboard layouts. Switching to US English solves the problem. The windows itself has English interface by default.

Thanks in advance for your hard work,
Grateful as always,
1nd1g0

14

Feature Requests and Suggestions / Re: Separate main GUI thread from internal operations.

« on: April 04, 2019, 02:25:48 »

I see your point. While writting native code, I had to refactor my apps modern-browsers-style, sacrifying system resources in favour of stability. So the whole GUI of my app was separated to an external process. Worker threads were hosted at separate non-gui process(es) with graceful self-desruction mechanism in case GUI process was killed somehow, to avoid orphans. Similar mechanism is used by Windows itself while hosting system services as threads in host processes, separate from GUI. The downside is one thread can freeze several neughbours and more data is duplicated in memory due to context separation. Windows does nothing with it so the whole service host process crashes and restarts. The thread that caused problems should be separated from others in "potentially problematic" host process ready to be killed and restarted from the of failrue or skipping it (depends on settings, user choices, algorythms etc.).

15

Feature Requests and Suggestions / Re: Separate main GUI thread from internal operations.

« on: March 28, 2019, 21:49:18 »

I stressed tabs GUI specifically. The whole window freezes when there are tab(s) with network paths that suddenly become unresponsive. It's a long time well-known problem. Possible reason could be that the main window thread and the thread used to update list views via system API requests (or some similar operation) are of the same context. Main window GUI would be worth making separate highest priority thread supervising the others via polling or flags. No direct calls with locks etc.

I hope it would not require huge application architecture changes and refactoring.

Do you need me to track down the culprit via debugger? (symbols would be nice)

16

Feature Requests and Suggestions / Separate main GUI thread from internal operations.

« on: March 27, 2019, 15:08:24 »

Hello there, Mathias, thanks a lot for your hard work.

Is there any chance for MC to get real multi-threading and separate threads for GUI tabs and device\network operations?
I know thread synchronization is not the easiest thing to do, but once done there will be huge improvement in overall usability.
Hanging the whole process including main window thread while waiting for file system API response is very problematic for active multi-tab users 
Let the tab show some progress animation or text, preferably with cancel button and you will be praised in centuries 

Thanks a lot in advance for your consideration.