Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - ags

Pages: 1 [2] 3
26
What I was trying to demonstrate here is this: MC already supports automatic verification of hashes when the user presses <Enter> on an *.md5 file.
This is very convenient for someone who is obligated to use hash verification often. MC offers tools for this (Extension -> File Checksum) but it is a cumbersome implementation and not straigh forward as in other file managers. When you have to do it once is ok, but many times a day it is not. Too many clicks for something that could and should be done by simply pressing <Enter>.

So, to simplify the life of the user, since the functionality already works for md5, it would be nice to work for the other file extensions that contain precalculated hashes.

27
Scenario
User creates a *.zip archive ("Internal zip" packing profile is selected) out of some files and directories; some of the directories are empty.

Observed behavior
MC does not pack the empty directories into the archive, they are ignored.
Also, if only empty directories are selected, MC creates an invalid zip file - no header, no nothing, 0 bytes.

Requested behavior
MC should respect the user's choice of data they want to pack. If there are empty directories selected for packing, they should be also found in the archive.

28
Scenario
- user downloads a file (https://mirror.yandex.ru/mirrors/MX-Linux/MX-ISOs/MX/Snapshots/MX-23.4_December_KDE.iso)
- user also downloads the checksum for the above file (https://mirror.yandex.ru/mirrors/MX-Linux/MX-ISOs/MX/Snapshots/MX-23.4_December_KDE.iso.sha512)

Observed behavior
- MC does not recognize hash file extensions other than *.md5

Requested behavior
- please add other extensions, like *.sha, *.sha1,*.sha256, *.sha512. So the user can check the *.iso by pressing <Enter> on the hash file.

29
Beta Releases / Re: v14.5 BETA
« on: December 22, 2024, 17:09:27 »
Quote
Try beta build 3053. I think I found the issue
I confirm the issue is not present in 3053. Thank you.

Quote
Zip and 7Zip are totally different
I know, that's why I did tests with both. I wanted for you to have more clues where to look for the problem.

Quote
Ok then It should been posted in other section..
Ah yes, sorry about that. I found the bug after update to 14.5.

30
Beta Releases / Re: v14.5 BETA
« on: December 22, 2024, 11:48:10 »
Update 1
Redid the compression with 14.4 with "Internal zip (normal)" packer profile - still creating corrupted archive.

Update 2
Redid the compression with 14.4 with "7-zip" packer profile - the archive is valid.

31
Beta Releases / Re: v14.5 BETA
« on: December 22, 2024, 11:32:43 »
This worked in 14.4 ?
There as been no changed to the 3rd party zip code.. But I will check

Hello! Thanks for replying.

I didn't have the old version anymore, haha, but trying to find more info on this, so:
- I redownloaded Multi Commander v14.4 (Build 3047) (32 bit)
- used 14.4 to recreate the archive with the exact dataset as with 14.5 BETA
It's exactly the same result, the archive is corrupted.

One more clue, in both 14.4 and 14.5 I used "Internal zip (max)" from Packer profiles.

32
Beta Releases / Re: v14.5 BETA
« on: December 21, 2024, 23:06:36 »
Just updated to 14.5 build 3051 BETA.

There are problems creating valid zip archives of larger sizes.

I needed to compress about 7 GiB of data and after finishing I opened the archive and I noticed I cannot find all my files in the newly created archive.
I tried to reproduce with another data, 5 GiB. The same results, not all files are found in the archive.
MC can open the archives and reports their size correctly. I know this because my files were not very compressible.

I used Double Commander to check the resulting MC archives and DC cannot open them, but DC can create valid archives out of exactly the same data.

Can somebody reproduce this? Just select some files until you make up about 5-7 GiB and then Alt + F5 and <Enter>.

33
There is an error, recommending to report it to an administrator.

34
Using MultiCommander_win32_Portable_(14.3.0.3042).

Scenario
Panel working in "List" mode. Objects ordered by name.
User enters an archive. MC places the cursor right above the objects in the archive, on the [..] sign.
User exits the archive and renames it, adding a character at the end of its name, for example.

Observed result
User enters the same archive again. MC places the cursor on the last object of the archive. This is always reproducible.
In one case of archive I tested though, the cursor was placed one object before last, but I don't know why was MC behavior different on that archive.
The type of the archive doesn't seem to matter - I tried zip, 7z.

Desired result
The cursor should be always placed on the [..] sign.

PS: This weird behavior happens only once after rename, in all the subsequent archive openings the cursor is on [..] position. So if after rename the user enters the archive 5 times, the first time the cursor is down, all the other times the cursor is up.

Update:
I just noticed similar behavior when renaming folders

35
Support and Feedback / Re: Is there a way to change the status bar?
« on: November 23, 2024, 12:35:04 »
Oh, nice! Thank you for the good news!

36
Support and Feedback / Is there a way to change the status bar?
« on: November 22, 2024, 18:06:56 »
In Speed Commander the status bar can be edited in a very convenient and professional way.

https://ibb.co/c1WZ8mT

Is there a way to do that in Multi Commander?
I am asking this because in List view mode Multi Commander does not show the much needed and useful info about the file under cursor, like the other orthodox file managers do.

37
Support and Feedback / Re: Unpack files function
« on: November 09, 2024, 17:57:38 »
It works, yes  :)

But there is a complicated, unintuitive path: after checking "Use target path as default location", the user has to unpack the archive in the current directory, not in the other side, because MC does not immediately change the path in "Unpack archives" dialog when the option is checked. The dialog also has to close for MC to save the option.
The next time the dialog is opened, the check mark will be set on "Use target path as default location" and the path from the other side will be filled in the "Unpack to" field.

To avoid all this, and provide the user with an important visual cue that the option"Use target path as default location" actually does something, can you please make MC automatically set the correct path in the field "Unpack to", at the event created when "Use target path as default location" gets checked?

38
Support and Feedback / Re: Unpack files function
« on: November 09, 2024, 13:15:32 »
Quote
Not sure what you issue is.
Quote
So my question still stands: I have an archive in panel A. I want to decompress it in panel B (that's why panel B is there - for convenience). My archive does not contain a top level directory so I want MC to create it for me, naming it like the archive. All in a single operation. How can I do that in MC?

OMG, man!

39
Support and Feedback / Re: Unpack files function
« on: November 09, 2024, 05:58:35 »
Quote
Most people expect unpack to end up in same folder. (since it was is happening by default in Windows explorer.)
This might be true to Windows Explorer, which does not have the other half, which the user can use for convenience.
MC is an orthodox file manager, meaning it has a dual panel interface. This is a very good idea, and all the operations and the default settings should be implemented considering this aspect. I am sure the other type of file managers, the Windows Explorer-like ones, also do things their way.
MC should not copy file managers from a different category.
Quote
But you can press the Target button and the entire path is change to the location of the Target panel.
and if you press the checkbox.. the default is change to always use the target panel location.
I know, but this does not help in any way with the creation of a directory for a single archive unpack.

So my question still stands: I have an archive in panel A. I want to decompress it in panel B (that's why panel B is there - for convenience). My archive does not contain a top level directory so I want MC to create it for me, naming it like the archive. All in a single operation. How can I do that in MC?

40
Support and Feedback / Re: Unpack files function
« on: November 08, 2024, 17:52:42 »
> That setting is if you select multiple files and want to unpack all of them into own subfolders.
Indeed, if the user selects more archives, the checkbox is automatically selected. A choice that seems a little odd to me.

>By default it should unpack it into a folder named after the archive.
Yes, but this happens in the same directory the archive is.
Consider this scenario:
- in the left side I have an archive;
- I want to unpack it in the right side, in a directory with the same name.
How can I do that fairly common operation with MC?

41
Support and Feedback / Unpack files function
« on: November 08, 2024, 15:44:24 »
Hello!  :)

Need to unpack files in directories that have the same name as the archive.
There is a check box for this, but it looks like it is greyed-out and cannot be used.

42
Support and Feedback / Archive testing function
« on: November 08, 2024, 12:18:07 »
Using build 3026.
There are some problems with the archive testing function.

1. There is no way for the users to know what archive they are testing if they move away from that archive. When I have many archives with similar names, and also multitask other things, it's useful to see the archive being tested.

2. In dark theme, MC shows black text on a dark background. Hard to read.

3. When testing is interrupted with ESC key, MC shows:
- that archive is 100% tested in the title bar, which is untrue, even though the progress bar is not at 100%
- a window informing the user that there are no errors, which MC has no way of knowing, because the operation did not finish. It could happen that the archive is corrupted but MC shows it is fine.

43
Support and Feedback / Re: Column autosizing in List view
« on: November 08, 2024, 09:15:21 »
Another bug in showing files in List view can be seen in the screenshot below.

In d:\Downloads directory I have many files, a few columns of them. You can see the scroll bar from the bottom.
MC does not calculate the number of columns correctly, since the last column is empty and should not exist.

44
Support and Feedback / Re: Column autosizing in List view
« on: November 08, 2024, 08:17:10 »
I don't know if managed to clearly explain the problem. I will try again.
I'll exemplify with a screenshot of firefox's source code below.
MC panel is set in List view mode.

The archives names in the first column are truncated with the simbol "..." at the end.
Some files with long names have useful info stored in that long name: date, time, uniqueID, software component etc.

When constantly changing directories that host such files, it is annoying to have to do a manual job that the file manager should automatically calculate and do for you.

Also, my monitor is wide enough so that those archives could be displayed in full.

For comparison, I attached a screenshot from Double Commander, in the same List view mode. DC is also free and on top of that open source and displays correctly long file names without users having to manually adjust the Names column.


45
Support and Feedback / Re: Column autosizing in List view
« on: November 06, 2024, 08:47:18 »
I know of and use or used the following orthodox file managers and they all know how to display long names, do it well and do it fast, without any problems or manual intervention:

- Total Commander
- Double Commander
- FreeCommanderXE
- EF Commander
- Speed Commander
- Unreal Commander
- Frigate
- ViewFD
- Far Manager
- Necromancer's Dos Navigator

How could practically anybody in the world have found a way to properly do an important task, but MC?

46
Support and Feedback / Re: Column autosizing in List view
« on: November 06, 2024, 07:46:36 »
I don't know about displaying the files on multiple lines. Wouldn't this create a very busy list, difficult to read, when the names of the files are of different lengths? Some of them would wrap on 2-3 lines, and some of them would remain one line?

Different workarounds can be found. But the fact remains: MC does not know how to handle files with long names. And in a world full of files with long names, this is a big problem, a bug. I am petitioning here for the fixing of this bug.

47
Support and Feedback / Re: Column autosizing in List view
« on: November 05, 2024, 14:33:32 »
So every time I enter a directory where I want to see long names I have to resize the Name column by double clicking the splitter?

48
Support and Feedback / Re: Column autosizing in List view
« on: November 04, 2024, 17:52:19 »
I am not sure we are on the right track here...  :D

The fact is that if MC wants to show long file names, it has to read the list of files, find the longest and adapt the column width to fit as many characters as possible.

Can you make this an automated process, like in the other file managers?

49
Support and Feedback / Re: Column autosizing in List view
« on: November 04, 2024, 16:03:49 »
Okay, unchecked the auto size of the columns. I can literally see no difference. It is exactly like the option does not have any effect.
I scroll through the list of files and I see about 50% of the name on all of them.

50
Support and Feedback / Proper column sizing in List view
« on: November 04, 2024, 14:56:56 »
Using build 3026 in List view mode.
Sorting and Columns -> Autosize columns is checked.

I have a lot of files with long names that I need to be able to see.

Expected behavior
MC would set the "Name" column width after the longest file/directory name. Or, if the name is very long, the width of the "Name" column would be equal to the width of the panel.

Obvserved behavior
MC badly truncates every name of my files and I can't read the information stored there. Why is this?

Pages: 1 [2] 3