Re: Pre-release for testing - UPDATE

  • From: <tpgww@xxxxxxxxxxx>
  • To: emelfm2@xxxxxxxxxxxxx
  • Date: Sat, 14 Jul 2007 11:09:16 +1000

On Fri, 13 Jul 2007 19:01:45 +0400
Alexander Orlov <alxorlov@xxxxxxxxx> wrote:

> On Fri, 13 Jul 2007 14:58:26 +1000
> <tpgww@xxxxxxxxxxx> wrote:
> > > 1) When I try to unload any sub-plugin from _Copy plugin, for example 
> > > "Copy with _times" emelfm2 segfaults. It happens in src/e2_plugins.c:264 
> > > in function g_module_symbol(), because of p->module = NULL. I have added 
> > > two strings before this function, to check p->module:
> > > 
> > > if (!p->module)
> > >   return FALSE;
> > > 
> > > and the problem gone.
> > The ACL plugin now has 2 actions, so I too was looking at the 
> > multi-action-plugin code again, just now.
> Sorry, I have no ACL support now, and I can not test it.

If you have linux kernel 2.6.x, you can change any mountpoint's data in your 
fstab, change an entry's parameter from, say, "defaults" to "rw,acl". And 
you'll need libacl and related development files, to build and use the plugin.

> > Some small bugs, including the one you mentioned, fixed already and in svn. 
> > BUT deleting "child" lines in a config dialog, for plugins like cpbar, is 
> > still not bulletproof. Fixing this turns out to be quite hard, I'm still 
> > looking into it. Really, the whole plugin (parent line in the dialog) 
> > should be deleted, or the child should just be flagged as off-menu instead 
> > of deleted.
> I think, that hiding plugin from menu is quite enough.
> The problem is now solved.
> You have been joined two checks (!p->module and g_module_symbol(...)) in one 
> 'if'. But are you sure, that compiler will not place g_module_symbol(...) 
> before !p->module? If so, the programm still will segfault in this place.

AFAIK it's a fundamental tenet of C that expressions are evaluated in order, 
subject to the language's precedence rules. If not, lots of other things in e2 
would also break !

Plugins config management still needs more work.

> > > 2) I have trouble with Find plugin. It allways serchs in / directory, 
> > > doesn't matter which directory I choose (active or other). When I choose 
> > > to search "anywhere" it does not search at all.
> > > When I choose to search in "this directory" and write path (for example 
> > > /tmp), it lanches find with this parms:
> > > 
> > > find -H / -maxdepth 1 -regex /tmp/?test
> > I can't get mine to do that. IIRC a long-ago chat with Liviu on the same 
> > matter, there might be a problem with the cached flags for the find plugin, 
> > as the ABI was changed a bit. In your cache file there'll be a line like
> > 
> >   find-plugin-flags=0,1,0,0 <and lots more 1's and 0's>
> > 
> > Does it help to delete that line and then try the plugin again ? 
> Yes, it helps. Now it works perfectly.
> By the way, older versions of findutils has no flags -HLP, and Find plugin did
> not worked for me, untill I updated findutils (previously I had
> findutils-4.1.7).
Yup, it's documented somewhere (certainly in my rpm .spec file, and on the e2 
website when it's up) that >= 4.2 is needed.

> > > 4) Tree view has many bugs.
> > > First of all it beeps and prints message "Cannot open directory //root - 
> > > Permission denied", every time it founds directory that it can not open. 
> > > This is very annoying.
> > Well, it depends on what is going on at the time. If you were in the midst 
> > of a recursive operation, you'd probably want to know that a directory 
> > can't be opened, and beeping happens for virtually all errors. So we need 
> > to identify cases where failure to open is not really an error. Any 
> > suggestions?
> > 
> > That aside, is that string:
> > 
> >   "Cannot open directory //root - Permission denied"
> > 
> > EXACTLY what was printed ? What was the actual path of the dir that failed 
> > to open ?
> When I move emel to / directory, and press Shift-F9, it opens tree-view, and
> prints just the message that I posted. Exactly with double '//'. In the
> tree-window everything is correct, except that there is no node "root".
> > > When I opens some node of the tree, it duplicates that node.
> > > The majority of nodes, that has other nodes, are shown as empty.
> > > Sometimes it mixes nodes and wrongly puts one directory into another.
> > Is this when just opening a directory for display in a filepane ? Or are we 
> > talking about some operation on directory contents ?
> No, I am just browsing through the directory tree.
> > I need some more specific description, to help figure out exactly what is 
> > going on. Can you please post an example or two, showing exactly what was 
> > intended, the paths of the dirs involved, and exactly what happend ?
> I have been made some screenshots, to show you what is going on. They are 
> located on
> First I open tree-view, and everytnig is OK, except that there is no "root" 
> directory (screen1). Then I expand /var (screen2), and it shows, that no 
> directory there contains child nodes, which is wrong. And there appears 
> another /var.
> I expand the second /var (screen3), and everytnihg is all right there. 
> I go in /tmp (screen4). As with /var, /tmp directory duplicates. I expand 
> /tmp/emelfm2 directory and there is /tmp/emelfm2/.wine-1000. But .wine-1000 
> is not in /tmp/emelfm2! It is in /tmp. /tmp/.wine-1000.
> I expand second /tmp (screen5), and everything is OK there, except that there 
> is no directories wich are inaccessible for me.
> Sorry, for my poor english, and for misunderstood, if any.

No problem, was my mistake. I was focused on my (former?) issue with filelist 
creation, and thought you were experiencing a variant of that, not the 
directory-tree view problems.

And now I see them:
 - if you don't have permission to read a directory, it should show without any 
descendants, instead of being omitted altogether (now fixed)
 - bad additions to the treeview widget, when scanning down a level (now fixed, 
I think)
 - some small bads in the text messages printed when a directory can't be 
opened (now fixed, but also, see below about warnings)

As to the error-beeps, I think that in these "tree" views, there does not need 
to be a warning message about dirs not opened, because "problem" dirs show in 
red text (or whatever color is set is for error messages). I've removed the 

Have a play with current svn code.


Users can unsubscribe from the list by sending email to 
emelfm2-request@xxxxxxxxxxxxx with 'unsubscribe' in the subject field or by 
logging into the web interface.

Other related posts: