Messages

May I jump into this with a question about the config file?

I was toying with making some toolbar rows invisible and decided I didn't like it but when I restored the toolbar to show 4 rows the bottom two had lost their application settings and commands.
Will deleting that config file restore the setting of the toolbar to stock?

Context menu does indeed work much better. Files are parsed correctly by all methods. Excellent.
See, I knew you could wield your magic.
No jumping around a chair on one leg while singing needed... though I did use a small coffee table!

1) Yeah, fair enough. Though that does require the extra step of enabling or adjusting the status of tooltips in the settings.
2) Maybe not an issue but it is odd behaviour when 'flat view' is in the same view menu as the other views: details,list,thumbnail. Those change of views don't require a forced refresh.
3) Agreed, the shell menu will find it difficult to process these files, only mentioned in the hope you might be able to do some 'magic' on them and have it work. Easy workaround is just to assign a hotkey or toolbar application to load them, that works just fine.

Couple of things I've noticed.

• It is very hard to see which folder is providing which file. Can the parent folder be displayed in the filename or perhaps an extra column could display to the far left that shows the folder?
  
• After changing the view back to a non-'flat view', you need to change to a folder further up the tree or another disk to force a refresh or use F2.
• Selected files are not being parsed correctly to 3rd party applications invoked by the context menu. The application either displays only the first document in both windows or only one instance is loaded. e.g. WinMerge with 'flat view' only the first file is used and is compared to itself. Or if two documents are sent to an editor only the first is sent, with different actions taken depending on the application, either two windows with the same document or just one with the second document discarded.
  This is true regardless of the name, even differently named files are not parsed correctly. However, files do appear to be handled correctly if drag/dropped onto an application in the toolbar.
  Likewise if drag/dropped into another folder, MU presents an option to merge them if they share the same name.

Thank you.

Since I have now started receiving the notifications from Microsoft about the free Win10 upgrade they are offering, I'm wondering if you know how MC will work/look with the new framework offered in Win10.

A couple of friends of mine with pre-release copies of Win10 have said some of their tools don't seem to work or look right in it, one notable though unsubstantiated claim was for 7zip not working.

I've placed my reservation for Win10 but I can't live without MC, it is just far too good to give up and I do a lot of file management to let it go.

With 5.1 I now get OneDrive and DropBox.
Still no icon for GoogleDrive, Box.net and Amazon's Cloud Drive. I imagine those three might be using a different api to the others and it isn't really a necessity to have them show up, just window dressing. All the functionality is still there.

I have exactly the same situation. I asked about this many months ago and just assumed it was an error specific to my machine but now it appears it can be replicated.

The only 'cloud' storage service that shows in my MC is DropBox. I have that and OneDrive, Box, Google Drive and Amazon's cloud drive.

3 replies too few? Is 4 replies enough?

Just kidding. It'sprobably because MC is so feature rich as it is.
If I had to choose a feature, I'd go with what @Jungle said, a flat view of the file list.

@Borg
It is precisely because Windows treats them as archives that I wrote this comment (TBH I'm not even 100% sure Windows does treat them as archives by default, but I'll take your word on it).
Windows will treat them as archives, UNTIL you install Java which then changes that behaviour to have them run as executables. It is MC's secondary step to change that behaviour that is odd.
I think you have completely misunderstood my comments if your response is:
"Just like treating .doc files as .zip (which they are) would not be that useful either."
Who said anything about that? In fact I used those filetypes as an argument against the current MC behaviour.
*.docx, *.odt and other Open-Source document formats ARE archives but Windows won't treat them as such because they are designed to opened by a specific program. So too *.jar. They are designed to be used by the JRE. No one uses *.jar as mere archives! They use *.7z, *.zip or *.rar or any other better compression format.

To summarise.

• People only ever come in to contact with *.jar files when, for whatever reason, they install a JRE, thus causing *.jar files to be viewed as programs.
  Jar files are only ever used to act as executables, not as an archive format.

At any rate, MC's viability is not dependent on my view of *.jar files and I still consider this to be the best file manager of all, free or otherwise.

I wonder if it is not just a case of the other program using the first icon it comes across in the cache and it just happens to be MC's.

Maybe a clearing of the cache will rectify it?
A tool like CCleaner can do it or open the Registry and navigate to:

Code Select Expand

HKCU\Software\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\TrayNotify

If the right hand pane contains IconStreams & PastIconsStream, delete those. Possibly a restart of Explorer is needed.

Just a thought.

<GrantSP> *sheepishly hides face*

Oops! Thanks. Rule number one: look through the settings BEFORE opening big mouth.

This should probably go in the Feature Request section but since the topic raised is fresh in mind, is it possible to have this action 'create' a new tab in the opposite panel, instead of trying to map the current open tab? The reason I ask is, most of the tabs I have are locked, and when you use this action it just errors out with the default error ding sound and no change if the destination panel is locked.

Thank you in advance and apologies for breaking conformity rules with the placement of this post.

hmm... that last comment was both disturbing and promising!

I actually agree with you about Java, however your/my view on its usefulness as an executable's platform isn't relevant, the standard of its handling is though.

At any rate, it isn't worthy of a lengthy discussion about that, I look forward eagerly to whatever new system you have devised.

Thank you again for your continued support and your fantastic software.

The default action on *.jar files should be to let JAVA run them because, as you say, they are JAVA.

The vast majority of people shouldn't be looking into *.jar files since they are never used as a means to package files form delivery but as an executable. I'm surprised you even phrased your comment the way you did, with mild sarcasm.

By all means allow MC the means to open them as an archive, BUT NOT as default.

The open-source document formats like *.ods & *.odt from programs like LibreOffice or OpenOffice are also compressed archives, using your logic, the default action for these will also be to open them in MC as an archived folder and examine the contents! I'm sure you agree that is the wrong thing to do.

I was not aware that you have received lots of requests to implement this function but, I'm sorry, regardless of the number of requests this is not the best way to treat those files.

The default action on ANY file, ie. the action performed by a double left-click, should be the same as the action Windows would perform on it if invoked from the commandline.
Call a *.txt file and the default action is to run the assigned text editor, call a *.jpg and your graphics editor/viewer will run, a *.zip and your archive program handles the file. Calling a *.jar would call the associated program. If you don't have JAVA then it probably would be an archive manager, but 99% of the time it will be JAVA.
Just how hard is it for people that want to do any non-default action on ANY filetype to setup a context menu action.

I hope you read this in the context in which it was written, not as an angry response, but as a bemused MC user that would like you to reconsider this position on the default actions for specific filetypes.

Thank you. As always your explanations are clear and concise.

Question though. Why are *.jar files added to that extension as archives by default? Surely in the majority of setups *.jar files should always be treated as executables?

[Explorer Panel Settings... --> Mouse Configurations --> Left/Right/Middle Mouse button -- Double click]

If you have the setting:
Explorer Panel Settings... --> Mouse Configurations --> Left/Right/Middle Mouse button -- Double click
set to:
Open folder/Execute File
Double clicking on a Java archive (*.jar) opens it as any other type of archive or folder, despite the fact that Windows is et to treat these as files NOT folders.
The default double-click action from an explorer window runs this as an executable.

Changing this setting to:
Execute File
in the settings panel correctly treats it as an executable, but I lose all folder navigation functionality.

Additionally changing this setting to:
Open Folder
doesn't actually enable open folders for me, no matter if they are *.jar, or any archive format, files or simply folders in the tree.

This is on Win7 64bit with MC v4.6 (build 1777)

I'm still unable to locate a file by pressing the keyboard letter it begins with .

Do others experience this same problem?

No, sorry, the error is with the user in this case.
The instructions to set this action are very precise and if followed they produce the exact result you are after.

I'd say there is something odd about your setup. The described action works exactly as it should for me.
It makes no difference whether the modifier key is pressed first or second, the combined key/mouse action does as it should.

[PERFECTLY]

Mathias, I am sorry, I kept checking for an update using "Help" -- "Check for updates" but nothing showed as being available.
It was only when I ran the MultiUpdate tool that a new update was provided.

Yes, as you say, there is now that option in the settings. And it works PERFECTLY!!

Just want I wanted. Thank you.

So can I conclude from this that the setting inside the MultiUpdate tool to also include 'beta' updates doesn't apply in the menu command?

[UP the path]

Settings if it should open new tab when going to new location of tab is locked is already added in the current beta

Somehow I think you are misunderstanding the point of this topic.

Regardless of whether I have the option checked or not, whenever I move UP the path a new Tab is opened.

"Lock Tab - Allow subpath change" is great, I use this ALL the time on my locked tabs. It keeps my locked Tab and all the sub-folders together.
That option is not in question. It does what you intended and what I need. It is the moving UP the path that is broken.
Sometimes when I click, " .. ", to move up the path, I sometimes click again by mistake and a new Tab opens with the parent folder.
It shouldn't! That is the aspect of 'Locking the Tab' that should be addressed.
A simple error message or audible error tone or something, just to alert the user, "Sorry, you don't want to go that way, you have locked the Tab."

Likewise clicking the higher level folders in the pathname shouldn't be possible when this option is chosen.

C:\TopLevel\SecondLevel\ThirdLevel\FourthLevel\FirstChildLevel\Folder1\Folder1a\Folder1b\

In this example the locked Tab is FourthLevel. All the folders under this should, and do, open in the same Tab.
Anything above that, C:, TopLevel, SecondLevel or ThirdLevel should return an error message of some kind indicating access from this 'Locked Tab' is denied.

Otherwise the functionality of 'locking the Tab' is gone. I can move freely up and down this directory tree without locking tabs, all locking them does is start a new Tab. If I wanted a new Tab I can simply Ctrl-T and make one using the current folder as a starting point.

[that specific tab]

I think my initial post was worded badly.

Yes there is the option to Lock it and allow changing to Sub-paths but it doesn't actually lock the going up in the way I imagined.
While it is true that, that specific tab doesn't move up, the opening of a new tab instantaneously with the parent folder is a bit of a poor option, IMO.

Perhaps a dialog box stating that, opening a new tab or remaining in the current locked tab, as options would be better.
If I lock a tab it is because there is no need to move up that path to do anything useful inside MC. If I truly need to go there I can do so myself with a new tab or some other method.

Locking a tab and allowing the user to go there with no problem is like having a password protected folder that has you password always available and opens at any attempt. Defeats the purpose.

Yes, password protection and locked tabs are different but they serve to illustrate the point.

Is it possible to lock a TAB from going UP the tree but still allow access to all the sub-folders under the currently selected location.

I have a folder that I access frequently and would like to get into the folders immediately below it but stay clear of those above it.

[Error! - Name Conflict]

I have a folder structure made up of 10 language versions of a selection of files.
The time has come to rename one of the files in each language folder to something else.

I ran a search inside MC to look for the filename as it is now and it correctly gave a list in the search results panel
So I selected all the files and ran Multi-Rename to change all the files to the new name.
Each time I tried the Multi-Rename spits back the error message:
Error! - Name Conflict

What am I doing wrong?

Any operation I try to do on this list results in this error.

Is the search list providing the Multi-Rename tool with the directory path as well or just a list of names that are all identical?
The search results panel certainly shows the full path but the Multi-Rename looks to be seeing them all in the same location.

If I use the list panel for other commands, like copy for example, it functions as expected.
The first file is copied and then on each subsequent copy the dialog for options on same named files appears.
Clearly it is correctly pulling each file from it's own folder in turn, as I would expect.

After much fiddling I find that the way to rename files on the search results is to use the Tools\Rename\Replace text in name command on the main menu.

This in my opinion this needs some attention.
The Multi-Rename tool is well suited to this operation and is probably looked to more often than this 3 level deep command.

Hope this will be of some help.

Thank you for your great software. I am an avid fan.

I was not trying to be obtuse. I was merely pointing out you said you formatted your system and are NOW having trouble with that hidden folder.
The problem as I see it is not with how MC views that hidden folder, but how your system sees it.

You appear to asking in the wrong forum for help.

As accomplished as Mathias is, and I have no connections with this software and its creator other than being an avid user, he surely shouldn't be expected to help fix a problem of this kind. What do the creators of that Wise software say?

No offence intended. No sleight on your reasoning is implied.